Method and device for updating MBN file

Abstract

The embodiment of the invention provides a method and device for updating an MBN file, relates to the field of terminals, and can improve the upgrading and updating efficiency of the MBN file. The method is applied to the electronic equipment and comprises the steps that first data are received from a cloud server, the first data comprise a first MBN file and a first version information file, and the first version information file is used for indicating the version of the first MBN file; under the condition that the version indicated by the first version information file is higher than the version indicated by the second version information file, updating a second MBN file of the first directory according to the first MBN file; the second version information file is used for indicating the version of the second MBN file; creating a soft link, wherein the soft link is used for enabling the first path to point to the first directory; switching the RFS path from the second path to the first path; and restarting the electronic equipment, and loading the updated MBN file from the first directory pointed by the first path.

Description

A method and apparatus for updating MBN files Technical Field

[0001] This application relates to the field of terminals, and more particularly to a method and apparatus for updating MBN files. Background Technology

[0002] The modem configuration binary (MBN) file is a binary file that configures the Qualcomm platform according to carrier and network requirements. The MBN file can integrate the modem's on-card parameters, including nonvolatile (NV) parameters and embedded file system (EFS) file parameters.

[0003] Currently, on newer Qualcomm platforms, considering that the AP has more storage space than the Modem, the MBN file can be stored in the application processor (AP), and then the Modem can access the MBN file stored in the AP based on the remote file storage (RFS) mechanism.

[0004] In the RFS mechanism, the modem can read all MBN files from the vendor / firmware_mnt / image / modem_pr path. However, the vendor / firmware_mnt / image / modem_pr path has read-only permissions, which means that MBN files under this path cannot be updated except through system version updates (flashing the device's system version using flashing tools or upgrading the device's system version based on HOTA), thus affecting the efficiency of MBN file upgrades. Summary of the Invention

[0005] This application provides a method and apparatus for updating MBN files, which can independently upgrade and update MBN files without requiring system version updates (i.e., flashing the device's system version using a flashing tool or upgrading the device's system version via HOTA), thereby improving the efficiency of MBN file upgrades and updates.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, a method for updating an MBN file is provided, applied to an electronic device. The method includes: receiving first data from a cloud server, the first data including a first MBN file and a first version information file, the first version information file indicating the version of the first MBN file; updating a second MBN file in a first directory according to the first MBN file if the version indicated by the first version information file is higher than the version indicated by a second version information file; wherein the second version information file indicates the version of the second MBN file; creating a symbolic link to make a first path point to the first directory; switching a remote file storage (RFS) path from the second path to the first path; the RFS path being a path used to load the MBN file, the second path being the default path for the RFS path; and restarting the electronic device to load the updated MBN file from the first directory pointed to by the first path.

[0008] Based on the method provided in this application embodiment, when the version indicated by the first version information file is higher than the version indicated by the second version information file, the second MBN file locally on the electronic device can be updated according to the first MBN file. The updated MBN file can be stored in the first directory (corresponding preset partition). The electronic device can also create a soft link, which is used to make the first path point to the first directory. Furthermore, the electronic device can switch the RFS path to the first path. In this way, the modem can read the MBN file from the first directory pointed to by the switched path (the first path, such as the RW path) based on the RFS mechanism. The MBN file in the first directory is the updated MBN file, thus the electronic device can read the updated MBN file. The electronic device can communicate (e.g., make calls) based on the updated MBN file, which can avoid the problem of abnormal communication function of the electronic device caused by changes in operator requirements. The method provided in this application embodiment can update the MBN file in the first directory through OTA upgrade (e.g., pushing the MBN file from a cloud server), without needing to upgrade the MBN file through system version updates (i.e., flashing the device's system version using a flashing tool or upgrading the device's system version based on HOTA), which can improve the efficiency of MBN file upgrades.

[0009] In one possible implementation, the method further includes: after the electronic device is powered on, detecting the system version number of the electronic device; if the system version number of the electronic device is updated, deleting the MBN file and symbolic links in the first directory, switching the RFS path from the first path to the second path; and restarting the electronic device. It should be noted that when the system version is updated, the MBN file in the vendor partition corresponding to the RO path (second path) is the latest MBN file. Therefore, when the system version is updated, it is necessary to switch the RFS path from the first path to the second path (RO path) so that the electronic device can read the latest MBN file from the RO path and communicate (e.g., make calls) based on the latest MBN file. This avoids problems caused by changes in operator requirements leading to abnormal communication functions of the electronic device, enabling fault escape.

[0010] In one possible implementation, the first data further includes a first digest file, which indicates the version of the first MBN file. After restarting the electronic device, the method further includes: determining whether the contents of the first digest file and a second digest file are consistent; wherein the second digest file is a digest file stored in the embedded file system (EFS) file of the modem of the electronic device; if the contents of the first digest file and the second digest file are inconsistent, the RFS path is switched from the first path to the second path. If the contents of the first digest file and the second digest file are inconsistent, it indicates that the current MBN file update has failed, and the MBN file in the first path may be corrupted. In the event of a failed MBN file update, the RFS path can be switched back to the default path (i.e., switched from the first path to the second path) to avoid errors when reading the MBN file from the first path.

[0011] In one possible implementation, before updating the second MBN file in the first directory based on the first MBN file, the method further includes: copying the second MBN file from the first partition (e.g., the vendor partition) to the first directory; the first partition is the storage area corresponding to the second path, and the second MBN file in the first partition is obtained by decompressing the binary file corresponding to the modem when the electronic device is powered on. This ensures that the first directory contains all the MBN files, and thus the MBN files in the first directory can be updated based on the MBN file (the first MBN file) pushed by the cloud server, improving the efficiency of MBN file upgrades and updates.

[0012] In one possible implementation, after copying the second MBN file from the first partition to the first directory, the method further includes: verifying the second MBN file in the first directory based on a first MD5 value and a second MD5 value; wherein the first MD5 value is the MD5 value of the second MBN file in the first partition calculated using the MD5 algorithm, and the second MD5 value is the MD5 value of the second MBN file in the first directory calculated using the MD5 algorithm; updating the second MBN file in the first directory based on the first MBN file includes: if the first MD5 value and the second MD5 value are the same, updating the second MBN file in the first directory based on the first MBN file. This avoids errors in copying the MBN file in the vendor partition (MBN files being tampered with or partially missing), thereby preventing the MBN file update in the first directory from failing.

[0013] In one possible implementation, after updating the second MBN file in the first directory based on the first MBN file, the method further includes: verifying the updated MBN file in the first directory based on a third MD5 value and a fourth MD5 value; wherein the third MD5 value is the MD5 value of the first MBN file in the first folder calculated using the MD5 algorithm, the first folder being used to store the first data received from the cloud server, and the fourth MD5 value is the MD5 value of the updated MBN file in the first directory calculated using the MD5 algorithm. This avoids errors in copying the MBN file (the first MBN file) in the first folder (MBN file being tampered with or partially missing), thereby preventing MBN file update failures in the first directory.

[0014] In one possible implementation, downloading the first data from the cloud server includes receiving an over-the-air (OTA) upgrade package from the cloud server, the OTA upgrade package including the first data. That is, the MBN file in the first directory can be updated via OTA upgrade, which can improve the efficiency of MBN file upgrades.

[0015] Secondly, this application provides a chip system including one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The aforementioned chip system can be applied to electronic devices including communication modules and memory. The interface circuits are used to receive signals from the memory of the electronic device and send the received signals to the processor, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device can perform the methods described in the first aspect and any of its possible design embodiments.

[0016] Thirdly, this application provides a computer-readable storage medium including computer instructions. When the computer instructions are executed on an electronic device (such as a mobile phone), they cause the electronic device to perform the methods described in the first aspect and any of its possible design embodiments.

[0017] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect and any possible design thereof.

[0018] Fifthly, embodiments of this application provide an apparatus for updating an MBN file, including a processor and a memory coupled together. The memory stores program instructions, which, when executed by the processor, cause the apparatus to implement the method described in the first aspect and any possible design of the method. The apparatus may be an electronic device or a server device; or it may be a component of an electronic device or a server device, such as a chip.

[0019] In a sixth aspect, embodiments of this application provide an apparatus for updating an MBN file. The apparatus can be divided into different logical units or modules according to their functions, and each unit or module performs different functions so that the apparatus performs the method described in the first aspect and any of its possible design schemes.

[0020] It is understood that the beneficial effects achieved by the chip system described in the second aspect, the computer-readable storage medium described in the third aspect, the computer program product described in the fourth aspect, and the apparatus described in the fifth and sixth aspects can be referred to the beneficial effects in the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0021] Figure 1 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0022] Figure 2 is a schematic diagram of the hardware and software architecture of an electronic device provided in an embodiment of this application;

[0023] Figure 3 is a schematic flowchart of a method provided in an embodiment of this application;

[0024] Figure 4 is a schematic diagram of first data sent by a cloud server according to an embodiment of this application;

[0025] Figure 5 is a schematic diagram of updating an MBN file according to an embodiment of this application;

[0026] Figure 6 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0027] Figure 7 is a schematic diagram of another method provided in an embodiment of this application;

[0028] Figure 8 is a schematic diagram of the structure of a chip system provided in an embodiment of this application. Detailed Implementation

[0029] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant concepts or technologies is given first:

[0030] Symbolic links, also known as soft links, are a special type of file that allows you to create a soft link to any path, pointing that path to any file or directory.

[0031] RFS mechanism: A mechanism provided by the Qualcomm platform to enable modems to access the MBN file stored in the AP.

[0032] Currently, the RFS mechanism supports modems loading MBN files stored in the access point (AP) from two paths. The first path is: vendor / firmware_mnt / image / modem_pr (this path has read-only permissions and can be called the RO path), and the second path is: / mnt / vendor / persist / rfs / shared (this path has read-write permissions and can be called the RW path). Due to technical limitations, the modem can only read the entire MBN file from either the RO path or the RW path; it cannot read portions of each path and combine them, nor can it read MBN files from other paths.

[0033] The MBN file in the RO path is extracted from the Modem binary file (e.g., NHLOS.bin) when the electronic device is first powered on (either the first power-on after the device leaves the factory or the first power-on after a system version update). Because the RO path has read-only permissions, the MBN file in the RO path cannot be updated except through system version updates (e.g., flashing the device's system version using a flashing tool or upgrading the device's system version via HOTA). The RW path belongs to (points to) the persist partition. The persist partition is used to store critical data from RF / driver modules, and its storage space is limited, unable to store all the MBN files. Therefore, the RW path is currently only theoretically usable.

[0034] Currently, modems can only load MBN files from the first path, and MBN files in the first path do not support independent upgrades. If a carrier needs to change its requirements, such as shutting down 2G / 3G networks, and the MBN file pre-installed in an electronic device (e.g., a mobile phone) only supports 2G / 3G calls and not 4G calls, the phone's calling function may malfunction. For example, if a carrier needs to add a new SIM card type, and the phone previously did not have this information pre-installed, the phone will be unable to load the relevant parameters after inserting the new SIM card (the one corresponding to the new SIM card type), leading to abnormal phone communication. In these scenarios, upgrading individual MBN files (the MBN files corresponding to the carrier with the changed requirements) can solve the problem. However, because MBN files in the first path do not support independent upgrades, they can only be updated via system version updates (using flashing tools to update the device's system version or via HOTA upgrades), reducing the efficiency of MBN file upgrades.

[0035] This application provides a method and apparatus for updating MBN files, which can independently upgrade and update MBN files without requiring system version updates (i.e., flashing the device's system version using a flashing tool or upgrading the device's system version via HOTA), thereby improving the efficiency of MBN file upgrades and updates.

[0036] The method provided in this application can be applied to electronic devices. These electronic devices may include, for example, mobile phones, tablets, desktop computers, laptops, handheld computers, ultra-mobile personal computers (UMPCs), netbooks, cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices. This application does not impose any special limitations on the specific type of electronic device.

[0037] The following description uses the hardware structure of electronic device 100 as an example. Figure 1 shows a schematic diagram of the hardware structure of electronic device 100.

[0038] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, Universal Serial Bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, camera 193, display screen 194, and Subscriber Identification Module (SIM) card interface 195, etc.

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

[0040] The processor 110 may include one or more processing units, such as an application processor (AP), a modem / baseband processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0041] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

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

[0043] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0044] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image and video playback, etc.). The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.).

[0045] In some embodiments, the processor 110 may include one or more interfaces. The USB interface 130 is an interface compliant with the USB standard specification, specifically a Mini USB interface, a Micro USB interface, a USB Type-C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used for data transfer between the electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices 100, such as AR devices.

[0046] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0047] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0048] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0049] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including Wireless Local Area Networks (WLAN) (such as Wi-Fi), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), NFC, and Infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0050] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with networks and other devices through wireless communication technology.

[0051] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0052] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), an Active-Matrix Organic Light-Emitting Diode (AMOLED), a Flexible Light-Emitting Diode (FLED), Mini LED, Micro LED, Micro-OLED, Quantum Dot Light-Emitting Diodes (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0053] In this embodiment of the application, the display screen can be a touch screen, which can receive user operations (e.g., first operation, second operation, etc.) to realize human-computer interaction.

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

[0055] Electronic device 100 can acquire images through ISP, camera 193, video codec, GPU, display screen 194, and application processor.

[0056] The software system of the AP in the aforementioned electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses an Android system with an AP as its layered architecture. TM Taking the system as an example, the software structure of the electronic device is illustrated.

[0057] As shown in Figure 2, a layered architecture divides the AP's software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TM The system consists of, from top to bottom, the application layer, the application framework layer, and the system libraries.

[0058] It should be understood that the layering of the AP shown in Figure 2 is merely exemplary. In actual implementation, the AP software may include more or fewer layers. For example, the AP software may also include a Hardware Abstraction Layer (HAL) and a Kernel Layer, etc., which is not limited in this application.

[0059] The application layer can include a series of application packages or Android. TM application package (Android) TM Packages (APKs) are applications such as call, text message, browser, chat application, and video player.

[0060] In some embodiments, the application layer also includes cloud push APK and broadcast listening service.

[0061] The CloudPush APK is used to receive CloudPush data (first data) from the cloud server and can decompress the first data to the CloudPush folder. The CloudPush APK can also compare the first version information file and the second version information file in the first data. If the version indicated by the first version information file is higher than the version indicated by the second version information file, the CloudPush APK can send a broadcast message instructing Qcril to copy the second MBN file from the vendor partition (first partition) to the first directory, copy the first MBN file from the CloudPush folder to the first directory, and update the second MBN file in the first directory according to the first MBN file.

[0062] The broadcast listening service is used to listen for broadcast messages sent by the Cloud Push APK. After listening for a broadcast message sent by the Cloud Push APK, the broadcast message can be sent to Qcril through the AIDL interface.

[0063] The application framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The APIs in the application framework layer can be Android... TM Interface Definition Language (Android) TM The API is defined by the Interface Definition Language (AIDL), and can also be called an AIDL interface. The application framework layer includes some predefined functions. The application framework layer may also include a notification manager, window manager, resource manager, content provider, and view system, etc.

[0064] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0065] In some embodiments, the system library also includes Qcril, a copy module (also known as a copy module), and a preset partition corresponding to the first directory.

[0066] Qcril is used to launch the copy module, which copies the second MBN file from the vendor partition to the first directory, copies the first MBN file from the cloud push folder to the first directory (the corresponding preset partition), and updates the second MBN file in the first directory (the corresponding preset partition) based on the first MBN file. Qcril can also create symbolic links so that the RW path (the first path) points to the first directory.

[0067] Referring again to Figure 2, the software architecture of the electronic device also includes the software components of the modem, which can run a Real-Time Operating System (RTOS). This is similar to the Android running in the AP. TM The difference between the systems is that RTOS is a single-task operating system, capable of handling only one process at a time. Android, on the other hand... TM The system can handle multiple processes at the same time.

[0068] The modem may include the Qualcomm Messaging Interface (QMI) and RFSAPI.

[0069] QMI is a multiprocessor inter-process communication interface provided by the Qualcomm platform, used for interaction between the access point (AP) and the modem. The AP can operate the modem through QMI, such as calling functions, reading data, and setting NV items.

[0070] In some embodiments, Qcril in the AP can call the RFS API via QMI to set the RFS path, for example, switching the RFS path from the RO path (second path) to the RW path (first path). Alternatively, it can also switch the RFS path from the RW path to the RO path.

[0071] When the Qcril in the AP calls the RFS API via QMI, the Modem can act as a client, and the AP can act as a server. The Modem can retrieve the necessary MBN files from the appropriate path (e.g., RO or RW path) for loading (selecting the MBN file corresponding to the inserted SIM card information). For example, if a SIM card from country X is inserted into the electronic device, the Modem determines that the SIM card's country code is country X and can select all MBN files for all operators in country X from the appropriate path (e.g., RO or RW path) and save them to the Modem's EFS storage space. Subsequently, the Modem can select and load the MBN file corresponding to the inserted SIM card information.

[0072] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. In the description of this application, unless otherwise stated, "at least one" refers to one or more, and "more than one" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0073] For ease of understanding, the following describes in detail the MBN file update method provided in the embodiments of this application with reference to the accompanying drawings.

[0074] As shown in Figure 3, this application provides a method for updating MBN files, using a mobile phone as an example, including:

[0075] 301. The cloud server pushes the first data to the mobile phone.

[0076] In some embodiments, a cloud server may send an OTA upgrade package to an electronic device (e.g., a mobile phone), and the OTA upgrade package may include first data. As shown in Figure 4, the first data may include a first MBN file, a first version information file, and a first dig file (first digest file).

[0077] The first MBN file may include one or more MBN files to be updated. The first version information file is a document file, such as a .txt or .xml file. The format of the first version information file may be agreed upon by the cloud server and the cloud push APK. The first version information file is used to indicate the version of the first MBN file. Alternatively, the first version information file can be used to indicate the version of the MBN file after updating the previous MBN file (the full set of MBN files saved on the phone) based on the first MBN file.

[0078] The first data includes a first dig file, which is a binary file (with the extension .dig) used to indicate the version of the first MBN file. Alternatively, it can indicate the version of the MBN file after updating the previous MBN file (the full MBN file saved on the phone) based on the first MBN file.

[0079] It should be noted that the first version information file and the first dig file serve different purposes. The first version information file is used by the cloud push APK of the electronic device to identify the version of the MBN file (first MBN file) sent (pushed) by the cloud server, while the first dig file is used by the modem of the electronic device to identify the version of the MBN file (first MBN file) sent by the cloud server.

[0080] 302. The mobile phone receives the first data sent by the cloud server.

[0081] In some embodiments, the mobile phone's Cloud Push APK can receive first data sent by the cloud server and decompress the first data to the Cloud Push folder. The path to the Cloud Push folder could be, for example, data / vendor / cota / para / mcfg_def.

[0082] 303. The mobile phone compares the first version information file with the second version information file to determine whether the version indicated by the first version information file is higher than the version indicated by the second version information file.

[0083] In some embodiments, the mobile phone's cloud-based APK can compare a first version information file with a second version information file. The second version information file is a version information file stored locally on the mobile phone, used to indicate the version of the MBN file (second MBN file) stored locally on the mobile phone.

[0084] In some embodiments, when the mobile phone first receives the first data sent by the cloud server, the RFS path is the default path (such as the RO path). In this case, the second MBN file can refer to the full / all MBN files stored in the partition pointed to by the RO path (such as the vendor partition). In this embodiment, the RFS path can be switched subsequently (for example, from the RO path to the RW path). After switching the path, if the mobile phone receives the first data sent by the cloud server, the second MBN file can refer to the full / all MBN files stored in the partition pointed to by the RW path (the RW path can be pointed to by a soft link to the preset partition corresponding to the first directory).

[0085] For example, suppose the version of the first MBN file is 1.10.24.101 and the version of the second MBN file is 1.10.24.102, which means that the version indicated by the first version information file is higher than the version indicated by the second version information file.

[0086] If the version indicated by the first version information file is higher than the version indicated by the second version information file, step 304 can be executed; otherwise, the process can be terminated.

[0087] 304. Copy the second MBN file from the vendor partition to the first directory, and update the second MBN file in the first directory according to the first MBN file in the cloud push folder.

[0088] The first directory can point to a preset partition, which can be a data partition in the AP.

[0089] In one possible implementation, after copying the second MBN file from the vendor partition to the preset partition, the MD5 algorithm can be used to check whether all MBN files in the vendor partition have been successfully copied.

[0090] For example, each MBN file in the vendor partition (the second MBN file) corresponds to an MD5 value (the first MD5 value). After copying the second MBN file from the vendor partition to the preset partition, the MD5 algorithm can be used to calculate the MD5 values ​​(second MD5 values) of all MBN files in the preset partition. The first and second MD5 values ​​can then be compared. If they match, the copying of all MBN files in the vendor partition was successful. If they do not match, the copying process failed (MBN files were modified or some were missing). In this case, the MBN file (second MBN file) can be copied again from the vendor partition to ensure successful copying.

[0091] Furthermore, the second MBN file in the first directory (corresponding preset partition) can be updated based on the first MBN file in the cloud push folder (i.e., the second MBN file in the preset partition is overwritten based on the first MBN file).

[0092] In this embodiment of the application, updating the second MBN file in the preset partition according to the first MBN file may include the following situations:

[0093] Scenario 1: The second MBN file contains an MBN file with the same operator (e.g., the first operator) as the first MBN file. In this case, the MBN file of the first operator in the second MBN file can be replaced with the first MBN file.

[0094] For example, as shown in Figure 5(a), suppose the first MBN file includes MBN file 1 and MBN file 2, which correspond to the mobile operator and the China Unicom operator, respectively. The second MBN file includes N (e.g., 10) MBN files, where MBN file 3 and MBN file 4 correspond to the mobile operator and the China Unicom operator, respectively. Then, MBN file 3 and MBN file 4 in the second MBN file can be replaced with MBN file 1 and MBN file 2.

[0095] Scenario 2: The second MBN file does not include an MBN file with the same operator (e.g., the first operator) as the first MBN file. In this case, the first MBN file can be added to the second MBN file.

[0096] For example, as shown in Figure 5(b), suppose the first MBN file includes MBN file 1, which corresponds to operator XX. The second MBN file includes N (e.g., 10) MBN files, but these N MBN files do not include the MBN file corresponding to operator XX. Then, MBN file 1 can be added to the second MBN file. That is, the updated second MBN file can include N+1 MBN files, with the newly added MBN file 1 corresponding to operator XX.

[0097] Furthermore, after updating the second MBN file in the first directory based on the first MBN file in the cloud push folder (first folder), the updated MBN file in the first directory can be verified based on the MD5 algorithm to ensure that the first MBN file in the cloud push folder is successfully copied.

[0098] For example, the first MBN file in the cloud push folder can correspond to an MD5 value (third MD5 value). After updating the second MBN file in the preset partition based on the first MBN file, the MD5 algorithm can be used to calculate the MD5 value (fourth MD5 value) of the updated MBN file (the newly added or replaced MBN file) in the preset partition. The third MD5 value and the fourth MD5 value can be compared. If the third MD5 value and the fourth MD5 value are the same, it means that the first MBN file in the cloud push folder was copied successfully. If the third MD5 value and the fourth MD5 value are different, it means that the copying of the first MBN file in the cloud push folder failed (the file was tampered with or part of the MBN file was missing). In this case, the second MBN file in the first directory can be updated again based on the first MBN file in the cloud push folder to ensure that the copying of the first MBN file in the cloud push folder was successful, thus ensuring that the update is successful.

[0099] 305. Create a symbolic link. A symbolic link is used to make the first path point to the first directory.

[0100] The first path is one of the paths specified by the Qualcomm platform for the modem to load MBN files. The first path is a read-write path, meaning that the permissions for the first path are read and write (readable and writable).

[0101] For example, the first path could be / mnt / vendor / persist / rfs / shared (i.e., the RW path). This first path can point to the persist partition. The persist partition is used to store critical data from modules such as RF / drivers, but its size is limited and cannot store all MBN files. In this implementation, a symbolic link can be created to make the first path point to a first directory, which can then point to a preset partition. This preset partition can be a data partition within the AP, with a large storage space (greater than a preset threshold) capable of storing all MBN files. This effectively "expands" the storage space of the persist partition, solving the problem of the limited size of the persist partition where the RW path resides.

[0102] 306. Switch the RFS path from the second path to the first path.

[0103] The RFS path is the path where the Modem loads the MBN file. The default (or initial) path of the RFS path can be the second path, meaning the Modem uses the second path to load the MBN file by default.

[0104] In this application, the electronic device can call the RFS interface to switch the default path for loading MBN files in the Modem (e.g., the second path) to the first path.

[0105] The second path is one of the paths specified by the Qualcomm platform for loading the MBN file in the modem. For example, the second path could be vendor / firmware_mnt / image / modem_pr (i.e., the RO path). The second path can point to the vendor partition. The vendor partition is a read-only partition.

[0106] Since the vendor partition pointed to by the second path is a read-only partition, it can only be updated via system version updates (flashing the device's system version using a flashing tool or upgrading the device's system version via HOTA), and does not support independent upgrades of MBN files, thus affecting the efficiency of MBN file upgrades. In this embodiment, the RFS path can be switched from the second path to the first path, and the first path can be symbolically linked to the first directory. The first directory can store all MBN files, and the first directory is a read-write directory, supporting upgrades of individual MBN files, thereby improving the efficiency of MBN file upgrades.

[0107] 307. Restart the electronic device and load the updated MBN file from the first directory pointed to by the first path.

[0108] It should be understood that restarting an electronic device can trigger the modem to reload the MBN file based on the RFS mechanism. Specifically, after restarting the electronic device, the modem can read the MBN file from the first directory pointed to by the switched path (first path) based on the RFS mechanism. The MBN file in the first directory is the updated MBN file. Thus, the electronic device can read the updated MBN file and conduct communication (e.g., making calls) based on the updated MBN file, avoiding problems caused by changes in operator requirements that could disrupt the communication function of the electronic device.

[0109] In this embodiment, the modem can also read its own recorded .dig file (the .dig file recorded in the modem's EFS file) and check if it matches the .dig file in the first directory. The .dig file in the first directory is the first .dig file sent by the cloud server. If the .dig file in the modem's EFS file is inconsistent with the .dig file in the first directory, the RFS refresh mechanism can be triggered to refresh the information of the MBN file recorded by the modem (e.g., the tail record file) based on all MBN files in the first directory. After a successful refresh, the .dig file in the EFS file can be replaced with the .dig file in the first directory to ensure consistency with the .dig file recorded by the AP (in the first directory).

[0110] In some embodiments, restarting an electronic device may refer to restarting the entire electronic device (i.e., a full system restart). In other embodiments, only the modem of the electronic device may be restarted (during the modem restart, the electronic device will experience a temporary loss of SIM card and network connection for a period of time (e.g., about 10 seconds), without affecting services that do not require network access.

[0111] Furthermore, after the electronic device is restarted, the following steps can be performed to determine whether the MBN file update was successful.

[0112] 308. Read the dig file in the EFS file of the Modem and determine whether the content of the dig file in the EFS file is consistent with the content of the dig file (the first dig file) sent by the cloud server.

[0113] In some embodiments, the Qcril module of the electronic device can call the interface of the modem to pass the dig file (first dig file) sent by the cloud server to the interface. The modem can read the dig file (second dig file, i.e., second digest file) in the EFS file, compare the dig file in the EFS file with the passed dig file (first dig file), and return the comparison result to the Qcril module.

[0114] If the comparison result shows that the content of the dig file in the EFS file is consistent with the content of the dig file sent by the cloud server (the first dig file), it indicates that the MNB file update was successful (i.e., the cloud server successfully pushed the MBN file, or the OTA upgrade of the MBN file was successful), and the process can end. If the comparison result shows that the content of the dig file in the EFS file is inconsistent with the content of the dig file sent by the cloud server (the first dig file), it indicates that the MNB file update failed (i.e., the cloud server failed to push the MBN file, or the OTA upgrade of the MBN file failed), and step 309 can be executed.

[0115] 309. Switch the RFS path from the first path back to the second path.

[0116] If the MBN file update fails, you can switch the RFS path back to the default path (i.e., switch from the first path to the second path) to avoid errors when reading the MBN file from the first path.

[0117] The following uses Figure 6 as an example to illustrate the relevant process of the method for updating MBN files provided in the embodiments of this application.

[0118] As shown in Figure 6, the electronic device may include an access point (AP) and a modem. The modem may include an EFS file, which contains a dig file. The modem may also include a tail record file, which contains the tail records of each MBN file. The modem may also include commonly used MBN files, such as the MBN file corresponding to the current SIM card.

[0119] Each time the electronic device is powered on, the modem can read the dig file based on the current RFS path. If the current RFS path is RO (the default path; before path switching, the modem reads the dig and MBN files from RO by default), the modem can read the dig file (e.g., dig2) from the vendor partition pointed to by the RO path. If the version information indicated by the dig file in the vendor partition differs from the version information indicated by the dig file in the modem's EFS file, the modem can refresh the tail record file based on the full / all MBN files (MBN1, MBN2, etc.) in the vendor partition. If an MBN file is updated, its tail record will also be updated. Then, the modem can refresh the dig file in the EFS file, that is, replace the dig file in the EFS file with the dig file from the vendor partition. Additionally, if the tail record of the commonly used MBN file stored in the modem is updated, the modem can read the corresponding MBN file (the operator's MBN file corresponding to the commonly used MBN file in the modem) from the vendor partition and replace the commonly used MBN file stored in the modem, thereby enabling the SIM card to be configured based on the updated MBN file.

[0120] The full / all MBN files (MBN1, MBN2, etc.) in the vendor partition are extracted from the Modem's binary file (NHLOS.bin) and mounted to the AP's mount directory / path during the initial power-on of the electronic device (either the first power-on after the device leaves the factory or the first power-on after a system version update). This mount directory / path is: / vendor / firmware_mnt / image / Modem_pr (i.e., the RO path). In other words, the MBN and dig files extracted from the Modem's binary file (NHLOS.bin) can be stored in the vendor partition corresponding to the RO path.

[0121] When the RFS path is the RW path (after path switching, the modem can read the dig file and MBN file from the RW path), the modem can read the dig file (e.g., dig1) from the preset partition pointed to by the first directory of the RW path symbolic link. If the version information indicated by the dig file in the preset partition is different from the version information indicated by the dig file in the modem's EFS file, the modem can refresh the tail record file based on the full / all MBN files in the preset partition. Then, the modem can refresh the dig file in the EFS file, that is, replace the dig file in the EFS file with the dig file from the preset partition. In addition, if the tail record of the commonly used MBN files stored in the modem is updated, the modem can read the corresponding MBN file (the operator's MBN file corresponding to the commonly used MBN file in the modem) from the preset partition and replace the commonly used MBN file stored in the modem, so that the SIM card can be configured based on the updated MBN file.

[0122] The MBN files (MBN1', MBN2', etc.) in the preset partition pointed to by the first directory are copied from the full / all MBN files in the vendor partition, and then updated (added or replaced) based on the MBN files to be updated sent by the cloud server. The dig file in the preset partition is the first dig file sent by the cloud server.

[0123] Based on the method provided in this application embodiment, an electronic device can receive first data (including a first MBN file and a first version information file) from a cloud server. If the version indicated by the first version information file is higher than the version indicated by the second version information file, the electronic device can update its local second MBN file according to the first MBN file. The updated MBN file can be stored in a first directory (corresponding preset partition). The electronic device can also create a soft link to make a first path point to the first directory. Furthermore, the electronic device can switch the RFS path to the first path. In this way, the modem can read the MBN file from the first directory pointed to by the switched path (first path) based on the RFS mechanism. The MBN file in the first directory is the updated MBN file. Therefore, the electronic device can read the updated MBN file and communicate (e.g., make calls) based on the updated MBN file, avoiding the problem of abnormal communication functions of the electronic device caused by changes in operator requirements.

[0124] Based on the method provided in this application embodiment, the MBN file in the first directory can be updated via OTA upgrade, without needing to upgrade the MBN file via system version update (i.e., by flashing the device's system version using a flashing tool or by upgrading the device's system version via HOTA), which can improve the efficiency of MBN file upgrade.

[0125] It should be noted that when an electronic device undergoes a system version update (such as a system version upgrade based on HOTA), the MBN file in the vendor partition corresponding to the RO path may be updated. The MBN file pushed by the cloud server once or multiple times (the first MBN file) can be merged into the system version's code. That is, in the case of a system version update, the MBN file in the vendor partition corresponding to the RO path is the latest MBN file. In this situation, it is necessary to switch the RFS path back to the RO path so that the modem can read the latest MBN file. To address this situation, this application embodiment provides a path switching method, as shown in Figure 7, including:

[0126] 701. Each time an electronic device is powered on, check whether the system version number of the electronic device has changed.

[0127] The system version number of an electronic device can refer to the version number of its operating system. This system version number is released by the operating system developers and can be updated continuously as the operating system is updated.

[0128] 702. If the system version number of the electronic device is updated, determine whether the current RFS path is an RW path.

[0129] An update to the system version number of an electronic device can mean that the system version number detected after the current power-on is different from the system version number detected after the previous power-on. For example, suppose the system version number detected after the current power-on is 1.1.2, and the system version number detected after the previous power-on was 1.1.1, then the system version number of the electronic device is considered to have been updated.

[0130] If the system version number of the electronic device is updated, determine whether the current RFS path is an RW path. If the current RFS path is an RW path, proceed to step 703; if the current RFS path is not an RW path (i.e., it is an RO path), the process can end.

[0131] 703. Delete the data and symbolic links in the preset partition pointed to by the first directory, and switch the RFS path from the RW path to the RO path.

[0132] Understandably, after a system version update (such as a HOTA-based system version upgrade), the MBN file in the vendor partition corresponding to the RO path will be the latest MBN file. Therefore, you can delete the data and symbolic links in the default partition pointed to by the first directory, switch the RFS path from the RW path to the RO path, and allow the modem to read the latest MBN file from the RO path.

[0133] 704. Restart the electronic device and load the MBN file from the vendor partition pointed to by the RO path.

[0134] When the system version is updated, the MBN file in the vendor partition corresponding to the RO path is the latest MBN file. Electronic devices can read the latest MBN file from the RO path and communicate (e.g., make calls) based on the latest MBN file. This can avoid problems caused by changes in operator requirements that may lead to abnormal communication functions of electronic devices, thus enabling fault escape.

[0135] This application provides an RFS path management mechanism. When the system version is updated, the RFS path can be switched to the RO path so that the modem can read the latest MBN file. When the system version is not updated, if cloud push data (first data) is received from the cloud server, the RFS path can be switched to the first path. In this way, the modem can read the MBN file from the first directory pointed to by the switched path (first path) based on the RFS mechanism. The MBN file in the first directory is the updated MBN file. Therefore, the electronic device can read the updated MBN file and conduct communication (e.g., make calls) based on the updated MBN file. This avoids the problem of communication malfunctions caused by changes in operator requirements, enabling fault recovery.

[0136] This application also provides a chip system, as shown in FIG8, which includes at least one processor 801 and at least one interface 802. The processor 801 (e.g., a modem or access point) and the interface 802 are interconnected via a line. For example, the interface 802 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface 802 can be used to send signals to other devices (e.g., the processor 801). Alternatively, the chip system may include a satellite communication processor, which includes a satellite protocol stack.

[0137] For example, interface 802 can read instructions stored in the memory of the electronic device and send those instructions to processor 801. When the instructions are executed by processor 801, the electronic device (as shown in FIG1) can perform the various steps in the above embodiments.

[0138] Of course, the chip system may also include other discrete components, and this application embodiment does not specifically limit this.

[0139] This application also provides a computer-readable storage medium including computer instructions that, when executed on an electronic device (as shown in FIG1), cause the electronic device to perform various functions or steps performed by the electronic device (e.g., a mobile phone) in the above method embodiments.

[0140] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps performed by the electronic device in the above method embodiments.

[0141] This application also provides a processing device, which can be divided into different logical units or modules according to function. Each unit or module performs different functions, so that the processing device performs the various functions or steps performed by the electronic device in the above method embodiments.

[0142] Through the above description of the embodiments, those skilled in the art can clearly understand that the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0144] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0145] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0146] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0147] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for updating an MBN file, characterized in that, The method, applied to an electronic device, includes: receiving first data from a cloud server, the first data including a first MBN file and a first version information file, the first version information file indicating the version of the first MBN file; updating a second MBN file in a first directory according to the first MBN file if the version indicated by the first version information file is higher than the version indicated by a second version information file; wherein the second version information file indicates the version of the second MBN file; creating a symbolic link to make a first path point to the first directory; switching a remote file storage (RFS) path from a second path to the first path; the RFS path being a path used to load the MBN file, the second path being the default path of the RFS path; and restarting the electronic device to load the updated MBN file from the first directory pointed to by the first path.

2. The method according to claim 1, characterized in that, The method further includes: after the electronic device is powered on, detecting the system version number of the electronic device; if the system version number of the electronic device is updated, deleting the MBN file and the symbolic link in the first directory, switching the RFS path from the first path to the second path; and restarting the electronic device.

3. The method according to claim 1, characterized in that, The first data also includes a first digest file, which is used to indicate the version of the first MBN file. After restarting the electronic device, the method further includes: determining whether the contents of the first digest file and the second digest file are consistent; wherein, the second digest file is a digest file stored in the embedded file system EFS file of the modem of the electronic device; if the contents of the first digest file and the second digest file are inconsistent, the RFS path is switched from the first path to the second path.

4. The method according to claim 1, characterized in that, Before updating the second MBN file in the first directory based on the first MBN file, the method further includes: copying the second MBN file in the first partition to the first directory; the first partition is the storage area corresponding to the second path, and the second MBN file in the first partition is obtained by decompressing the binary file corresponding to the Modem when the electronic device is powered on.

5. The method according to claim 4, characterized in that, After copying the second MBN file from the first partition to the first directory, the method further includes: verifying the second MBN file in the first directory based on a first MD5 value and a second MD5 value; wherein the first MD5 value is the MD5 value of the second MBN file in the first partition calculated according to the MD5 algorithm, and the second MD5 value is the MD5 value of the second MBN file in the first directory calculated according to the MD5 algorithm; updating the second MBN file in the first directory based on the first MBN file includes: updating the second MBN file in the first directory based on the first MBN file if the first MD5 value and the second MD5 value are the same.

6. The method according to any one of claims 1-5, characterized in that, After updating the second MBN file in the first directory based on the first MBN file, the method further includes: verifying the updated MBN file in the first directory based on a third MD5 value and a fourth MD5 value; wherein the third MD5 value is the MD5 value of the first MBN file in the first folder calculated according to the MD5 algorithm, the first folder is used to store the first data received from the cloud server, and the fourth MD5 value is the MD5 value of the updated MBN file in the first directory calculated according to the MD5 algorithm.

7. The method according to any one of claims 1-6, characterized in that, Receiving the first data from the cloud server includes receiving an over-the-air (OTA) upgrade package from the cloud server, wherein the OTA upgrade package includes the first data.

8. An electronic device, characterized in that, The electronic device includes: a wireless communication module, a memory, and one or more processors; the wireless communication module, the memory, and the processors are coupled; wherein the memory is used to store computer program code, the computer program code including computer instructions; when the computer instructions are executed by the processor, the electronic device performs the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, Includes computer instructions; when the computer instructions are executed on an electronic device, they cause the electronic device to perform the method as described in any one of claims 1-7.

10. A chip system, characterized in that, The chip system includes one or more interface circuits and one or more processors; the interface circuits and the processors are interconnected via lines; the chip system is applied to an electronic device including a communication module and a memory; the interface circuits are used to receive signals from the memory and send the signals to the processor, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device performs the method as described in any one of claims 1-7.

Images