WO2011127845A2 - 一种移动通信终端间进行系统升级的方法、系统及终端 - Google Patents

一种移动通信终端间进行系统升级的方法、系统及终端 Download PDF

Info

Publication number
WO2011127845A2
WO2011127845A2 PCT/CN2011/073643 CN2011073643W WO2011127845A2 WO 2011127845 A2 WO2011127845 A2 WO 2011127845A2 CN 2011073643 W CN2011073643 W CN 2011073643W WO 2011127845 A2 WO2011127845 A2 WO 2011127845A2
Authority
WO
WIPO (PCT)
Prior art keywords
mobile terminal
hardware
sub
compatible
update
Prior art date
Application number
PCT/CN2011/073643
Other languages
English (en)
French (fr)
Other versions
WO2011127845A3 (zh
Inventor
林亮
Original Assignee
华为终端有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为终端有限公司 filed Critical 华为终端有限公司
Priority to EP11768456.3A priority Critical patent/EP2675110B1/en
Priority to PCT/CN2011/073643 priority patent/WO2011127845A2/zh
Priority to CN201180000646.4A priority patent/CN102232304B/zh
Publication of WO2011127845A2 publication Critical patent/WO2011127845A2/zh
Publication of WO2011127845A3 publication Critical patent/WO2011127845A3/zh
Priority to US14/070,818 priority patent/US9301164B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Definitions

  • FIG. 1 is a schematic diagram of a prior art wireless upgrade.
  • the wireless upgrade is usually through the OTA (Over-the-Air Technology) method. You need to download the upgrade package from the carrier's upgrade server to the phone cache cache partition or SD card (Secure Digital Memory Card). Start the installation, considering the cost of the download process, the upgrade package should be as small as possible, so the differential method is generally used. However, there are still variables in the OTA upgrade process, which may be undetected bugs or power outages during upgrades.
  • OTA Over-the-Air Technology
  • FIG. 1A is a schematic diagram of a process of backing up/restoring an Android system in the prior art.
  • a dotted line indicates the contents of the backup/restore
  • a dotted arrow indicates the backup/restore operation.
  • the prior art upgrade method relies on a professional upgrade server, and the upgrade is not convenient, which is disadvantageous for exchanging or updating the system between users. Moreover, the upgrade method of the prior art does not consider whether the system upgrade file written to the mobile phone is compatible with the hardware version of the mobile phone, so there is a risk of the upgrade failure. Once the upgrade fails, the function of the mobile phone cannot be used normally, and the upgrade of the prior art The method also has shortcomings in terms of security.
  • An object of the present invention is to provide a method, system and terminal for system upgrade between mobile terminals, which makes the upgrade of the mobile terminal more convenient and safe, and no longer relies on a professional operator to upgrade the server, and at the same time, the upgrade is successful. Rate, reduce the risk of malfunction caused by the failure of the mobile terminal upgrade.
  • an embodiment of the present invention provides a method for system upgrade between mobile communication terminals, where the method includes: determining, by a target mobile terminal, whether the source mobile terminal is hardware compatible; The target mobile terminal acquires the system backup file transmitted by the source mobile terminal through the wireless network; the target mobile terminal performs system upgrade according to the system backup file.
  • an embodiment of the present invention provides a mobile communication terminal, including: a wireless communication unit, configured to establish a wireless connection with a source mobile terminal that provides a system backup file, and obtain hardware information of the source mobile terminal.
  • a hardware compatibility determining unit configured to determine, according to the hardware information of the source mobile terminal, whether it is compatible with the source mobile terminal hardware; when the hardware is compatible, trigger the wireless communication unit to acquire a system backup file from the source mobile terminal; a unit, configured to perform a system upgrade according to the system backup file.
  • an embodiment of the present invention provides a system for performing system upgrade between mobile communication terminals, including: a target mobile terminal, configured to acquire hardware information of a source mobile terminal, and according to the source mobile terminal Hardware information, determining whether it is compatible with the source mobile terminal hardware; acquiring the system backup file from the source mobile terminal when the hardware is compatible; and performing system upgrade according to the system backup file; the source mobile terminal, and the target mobile terminal a wireless connection, configured to provide the target mobile terminal with hardware information of the source mobile terminal and the system backup file.
  • the technical solution provided by the embodiment of the present invention has the advantages that the system can be upgraded through the wireless network, and the system is no longer dependent on the upgrade server, and the upgrade file cannot be downloaded from the upgrade server, which can reduce the burden of upgrading the server, and is also beneficial to the mobile device.
  • Mobile phone users can easily exchange their own systems to achieve system upgrades. By judging whether the hardware of both parties is compatible before upgrading, it is beneficial to ensure the success rate of the upgrade.
  • Embodiments of the present invention allow users to have more convenient upgrade options to choose from, rather than relying entirely on carrier servers or professionals.
  • FIG. 1 is a schematic diagram of a prior art wireless upgrade
  • 1A is a schematic diagram of a process of backing up/restoring an Android system in the prior art
  • FIG. 2 is a schematic structural diagram of a system for performing system upgrade between mobile communication terminals according to an embodiment of the present invention
  • FIG. 3 is a functional block diagram of a mobile communication terminal according to an embodiment of the present invention.
  • 3A is a functional block diagram of another mobile communication terminal according to an embodiment of the present invention.
  • FIG. 3B is a detailed functional block diagram of the kernel driver update unit in FIG. 3A according to an embodiment of the present invention
  • FIG. 4 is a flowchart of a method for performing system upgrade between mobile communication terminals according to an embodiment of the present invention
  • FIG. 5 is a flowchart of an example of an inter-mobile phone upgrade system according to an embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of a system backup package according to an embodiment of the present invention.
  • FIG. 8 is a diagram of an installation-free startup process of a mobile communication terminal according to an embodiment of the present invention.
  • FIG. 9 is a flow chart showing the interaction between the driver module and the system data management module in the internal drive of the mobile communication terminal according to the embodiment of the present invention.
  • the user mobile communication terminal such as a mobile phone
  • FIG. 2 is a schematic structural diagram of a system for performing system upgrade between mobile communication terminals according to an embodiment of the present invention. As shown in Figure 2, the system includes:
  • a target mobile terminal configured to obtain hardware information of the source mobile terminal, determine, according to hardware information of the source mobile terminal, whether it is compatible with the source mobile terminal hardware; when the hardware is compatible, obtain a system backup file from the source mobile terminal; and according to the foregoing system Backup files for system upgrades;
  • the source mobile terminal is wirelessly connected to the target mobile terminal, and is configured to provide the target mobile terminal with hardware information of the source mobile terminal and the system backup file.
  • Bluetooth and WIFI are a free communication method between mobile phones, in which WIFI speed is relatively block.
  • the target mobile terminal and the source mobile terminal can connect and transmit hardware information and system backup files through the short-range wireless network described above.
  • the hardware information may include: a hardware version identifier, a board ID, a sub-hardware version number, key hardware information including processor information, memory information, and network type, and a driver identifier, DriverlD.
  • the network types include: CDMA (Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), TD-SCDMA (Time Division-Synchronous) Code Division Multiple Access, GSM (Global System for Mobile Communications), etc.
  • the system backup file may be stored on the SD card or stored in the backup area of the mobile terminal itself.
  • the system backup file can be a backup of the entire system of the mobile terminal, such as an image file including a modem modem and an operating system image file.
  • the Modem image file includes, for example: Qcsbl (Qualcomm Secondary Bootloader, Qualcomm's secondary bootloader), Oemsbl (OEM Secondary Bootloader, vendor's secondary bootloader), MODEM Firmware (modem firmware, ie modem's communication protocol stack) , OEMINFO (vendor information), etc. It is also possible to back up only a portion, such as only the boot program in the operating system, the operating system kernel, and the recovery program.
  • the above operating systems may include: Android system, Windows Mobile, and the like.
  • the source mobile terminal and the target mobile terminal described above may be dual-core or mobile communication terminals having more processors.
  • the two mobile terminals perform system upgrade and update through a wireless communication network such as Bluetooth or WIFI, and no longer rely on a professional operator to upgrade the server or the professional, and the upgrade of the mobile terminal is more convenient;
  • Compatible, and transfer system backup files for system upgrade when compatible which is beneficial to ensure the success rate of upgrade, and reduce the risk of upgrade failure of mobile terminals, so that the target mobile terminal that expects system upgrade will not be used normally due to upgrade failure.
  • Fig. 3 is a functional block diagram of a mobile communication terminal according to an embodiment of the present invention. As shown in FIG. 3, it includes: a wireless communication unit 10, configured to establish a wireless connection with a source mobile terminal that provides a system backup file, and obtain hardware information of the source mobile terminal; a hardware compatibility determining unit 12, configured to use the source mobile terminal The hardware information is determined to be compatible with the source mobile terminal hardware; when the hardware is compatible, the wireless communication unit is triggered to obtain a system backup file from the source mobile terminal; and the system upgrading unit 14 is configured to perform system upgrade according to the system backup file. Since the data interaction between the two mobile terminals is involved, when necessary, for example, when the target mobile terminal acquires the hardware information of the source mobile terminal, and when the system backup file is obtained from the source mobile terminal, the interaction between the two parties requires user operation confirmation.
  • the hardware information includes: a hardware version identifier BoardID
  • the hardware compatibility determining unit 12 is further configured to determine that the hardware compatibility of the two parties is the same when the mobile communication terminal and the source mobile terminal have the same BoardID.
  • the foregoing hardware information further includes: a sub-hardware version number, where the hardware compatibility judging unit 12 is further configured to: when the mobile communication terminal is different from the board ID of the source mobile terminal and the sub-hardware version numbers are the same, determine that the hardware compatibility of the two parties is compatible.
  • the foregoing hardware information further includes: processor information, memory information, and network type, and the hardware compatibility judgment sheet.
  • the element 12 can be specifically used to: when the mobile communication terminal and the source mobile terminal have different BoardlD and sub-hardware version numbers, further determine the processor information of both parties (for example, Qualcomm's MSM7201A/MSM8255 chip, MARVELL PXA320 chip), and memory. Information (such as Samsung's NAND FLASH model KA524GACB-A050, Hyundai hynix's NAND FLASH model H8BCS0UN0MCR-4EM) and network type are the same, if different, it is determined that the hardware is not compatible.
  • the foregoing hardware information further includes: a driver identifier DriverlD, where the hardware compatibility determining unit 12 is specifically configured to: when the mobile communication terminal and the source mobile terminal have different BoardlD and sub-hardware version numbers, and the processor information and the memory information of the two sides are When the network type is the same, it is further determined whether the DriverrlDs of both parties are the same. If they are the same, it is determined that the hardware of both parties is compatible.
  • a driver identifier DriverlD the hardware compatibility determining unit 12 is specifically configured to: when the mobile communication terminal and the source mobile terminal have different BoardlD and sub-hardware version numbers, and the processor information and the memory information of the two sides are When the network type is the same, it is further determined whether the DriverrlDs of both parties are the same. If they are the same, it is determined that the hardware of both parties is compatible.
  • the hardware compatibility judging unit 12 may be further configured to determine whether its own DriverlD exists in a set of DriverlDs of the same type of hardware of the source mobile terminal when its own DriverlD is different from the DriverlD of the source mobile terminal, and if so, determine the drivers of both sides.
  • Compatible that is, hardware compatibility is met.
  • the plug-and-pull detection processing of the interface of the hardware peripheral of the T-Flash card there are two working modes of interrupt and polling. The interrupt mode requires an additional interrupt pin on the hardware, and polling is not required, so The same hardware peripheral interface requires two software drivers: DriverlDlOl and DriverID102.
  • the source mobile terminal When the T-Flash card of the target mobile communication terminal that is expected to be upgraded is running the driver ID101, the source mobile terminal is using the DriverID102, but the source mobile terminal.
  • the user data storage space has the configuration data of DriverlDlOl, and the configuration data can be loaded and run, so that the target mobile communication terminal is still compatible with the T-Flash card interface of the source mobile terminal.
  • the system upgrading unit 14 is specifically configured to install the obtained system backup file for system update; or, if the system backup file is not installed, directly start the system backup file. Security can be guaranteed by installing the system directly from the system backup file without installing it.
  • FIG. 3A is a functional block diagram of another mobile communication terminal according to an embodiment of the present invention.
  • the mobile communication terminal further includes: a kernel driver updating unit, configured to update a kernel driver of an operating system of the mobile communication terminal according to the driver configuration data included in the system backup file.
  • a kernel driver updating unit configured to update a kernel driver of an operating system of the mobile communication terminal according to the driver configuration data included in the system backup file.
  • FIG. 3B is a detailed functional block diagram of the kernel driver update unit in FIG. 3A according to an embodiment of the present invention. As shown in FIG. 3B, the kernel driver update unit 16 specifically includes:
  • the driver configuration data module 162 is configured to obtain driver configuration data; for example, obtained from an upgrade package carrying a system backup file, or obtained from a user space if the system backup file has been installed.
  • the Sys file system module 164 is configured to import the drive configuration data into a kernel of an operating system of the target mobile communication terminal; or to export the kernel-driven configuration data for storage.
  • the system data management module 166 is configured to map the driver configuration data imported by the Sys file system module into a configuration data link table, where the configuration data link table includes: a processing point serial number, and a sub processing function number corresponding to the processing point serial number And a parameter of the sub-processing function; when the kernel driver needs to be updated, searching for a processing point corresponding to the processing point sequence number in the configuration data link table according to the processing point number; according to the searched processing point and the configuration data link table Obtaining a sub-processing function number corresponding to the processing point and a parameter of the sub-processing function; calling a sub-processing function corresponding to the sub-processing function number in the sub-processing function library, and passing in parameters of the sub-processing function to update the kernel drive;
  • the driving module 168 is configured to enable the system data management module to perform kernel driver update, and send a processing point serial number to the system data management module.
  • the advantages of the embodiment of the present invention are as follows: 1. The burden of upgrading the server can be alleviated; 2. The free communication mode is adopted to realize convenient and safe transfer of the mobile phone system between the user's mobile phones; 3. The backup file can be directly loaded into the system, free of Installation, is the safest way to upgrade; 4, the implementation of the kernel driver update.
  • FIG. 4 is a flowchart of a method for performing system upgrade between mobile communication terminals according to an embodiment of the present invention. As shown in FIG. 4, the method includes:
  • Step 200 The target mobile terminal determines whether the source mobile terminal is compatible with the hardware.
  • Step 210 When the hardware of both parties is compatible, the target mobile terminal acquires a system backup file transmitted by the source mobile terminal through the wireless network.
  • Step 220 The target mobile terminal performs system upgrade according to the system backup file.
  • the step 200 may specifically include: determining, by the target mobile terminal, whether the source mobile terminal has the same hardware version identifier BoardID, and if yes, determining that the hardware of both parties is compatible.
  • the target mobile terminal determines that the hardware version identifier BoardID of the source mobile terminal is different, the target mobile terminal further determines whether the child hardware version numbers of the two parties are the same, and if the same, determines that the hardware of both parties is compatible.
  • the target mobile terminal determines that the sub-hardware version number of the source mobile terminal is different from the source mobile terminal, the target mobile terminal further determines whether the processor, the memory, and the network type of the two parties are the same, and if different, determines that the hardware of the two parties is incompatible.
  • the target mobile terminal determines whether the driver identifiers DriverlD of the two parties are the same. When the same, the two parties are determined to be compatible and hardware compatible. Or determining whether the software driver identifier of the target mobile terminal is included in the set of the driver identifiers of the source mobile terminal, and if yes, determining that the target mobile terminal is compatible with the driving of the source mobile terminal; otherwise, the driver is incompatible. Alternatively, the target mobile terminal obtains a list of the source mobile terminal's DriverlD containing all peripherals, and A list of its own DriverlD containing all peripherals is compared. When the DriverrlD of each peripheral is the same, it is determined that the target mobile terminal is compatible with the source mobile terminal.
  • the method shown in FIG. 4 further includes: displaying a hardware compatibility report or a hardware compatibility index between the target mobile terminal and the source mobile terminal on the human-machine interface of the target mobile terminal.
  • the hardware compatibility report may include: The board IDs of both parties are the same, and the hardware is fully compatible; the board IDs of the two parties are different but the sub-hardware version numbers are the same, and the hardware is basically compatible; the B 0 ardID, the sub-hardware version number, the CPU, the memory, and the network type of both sides are both Different, the hardware is not compatible; the board ID and sub-hardware version number of the two sides are different, the two sides, the CPU, the memory and the network type are the same and the drivers of the two sides are compatible, and the hardware is basically compatible; the board ID and the sub-hardware version number of the two sides are different, the CPU and memory of both sides are different.
  • the hardware compatibility index is assigned 100%, for hardware basic compatibility, the hardware compatibility index is 60%, and for hardware incompatibility, the hardware compatibility index is 30%.
  • the specific process of the step 200 includes: the target mobile terminal installs the obtained system backup file to perform system update; or the target mobile terminal does not install the system backup file, and directly starts the system backup file.
  • the system backup file includes: a system boot boot file, an operating system kernel, and an operating system.
  • the system backup file may further include: a communication protocol stack and/or user configuration data.
  • the user configuration data can be used to update the kernel driver of the operating system of the mobile communication terminal.
  • the method further includes: exporting and saving a file corresponding to the incompatible driver between the target mobile terminal and the source mobile terminal.
  • the method shown in FIG. 4 may further include the steps of: acquiring driver configuration data; importing the driver configuration data into a kernel of an operating system of the target mobile communication terminal; mapping the driver configuration data into a configuration data link table,
  • the configuration data link table includes: a processing point serial number, and a sub-processing function number and a sub-processing function parameter corresponding to the processing point serial number; when the kernel driver needs to be updated, searching for the location in the configuration data link table according to the processing point serial number a processing point corresponding to the processing point number; obtaining, according to the searched processing point and the configuration data link table, a sub-processing function number corresponding to the processing point; and calling a sub-processing function library corresponding to the sub-processing function number
  • the child handler and passed in the parameters of the child handler to update the kernel driver.
  • FIG. 5 is a flowchart of an example of an inter-mobile phone upgrade system according to an embodiment of the present invention. As shown in Figure 5, the process includes the following steps:
  • Step 300 Confirm whether the hardware of the target mobile terminal and the source mobile terminal are compatible by interaction between the mobile terminals. According to the hardware compatibility, an index value indicating the degree of compatibility is displayed on the graphical user interface (UI, User Interface) of the mobile communication terminal for the user to decide whether to perform the transmission and upgrade of the upgrade package.
  • UI graphical user interface
  • Step 1 The module responsible for the interaction between the source terminal and the target terminal first obtains the hardware version identifier BoardID of the unified planning of the manufacturer by reading the /proc file system, and then compares whether the board IDs of the two parties are the same. If they are the same, the hardware of both parties is judged. The exact same, that is, the compatibility index is 100%, the compatibility indicator can be presented to the user for reference. If they are not the same, it is further determined whether the sub-hardware version numbers are the same. Since the BoardID also includes the major version number and the sub-version number, if the major version numbers are the same but the sub-version numbers are different, it is basically compatible, or is not completely compatible.
  • Step 2 By reading the /proc file system, you can get the key information of both CPU, memory RAM/ROM, network type CDMA/WCDMA/TD-SCDMA/GSM. Determine whether the CPU and memory RAM/ROM network types of the two parties are the same, CDMA/WCDMA/TD-SCDMA/GSM are the same. If they are the same, they are basically compatible, that is, the system can be started, it will not become a "brick", and the compatibility index displayed to the user is displayed. For example, 60%. It is also necessary to further judge whether other driving information is the same; when the information is different, it is judged that the hardware of the two parties is incompatible, for example, the compatibility index is 30%.
  • Step 3 View the information of other drivers through the sysfs file system /sys/devices/platform/, that is, the software driver ID DriverID that is uniformly planned by the manufacturer.
  • the sysfs file system is similar to the Windows registry. It is a file system that exports the internal objects of the kernel and their relationships and objects. It organizes the devices, buses, and drivers connected to the system into a hierarchy. The file, which the kernel starts with, mounts the root partition. After disabling sysfs, you need to specify the root partition using the device number in the kernel boot parameters. Each driver has a corresponding processing point in the sysfs file system, and the driver code supports reading each driver configuration information. If DriverlD is the same, the driver is compatible. If different, you can check whether the default DriverlD of the mobile phone to be upgraded exists in the DriverlD collection of the same hardware device of the source phone that provides the upgrade package. If it exists, it is judged to be compatible.
  • Step 4 If a DriverlD is not compatible, you can export the configuration information separately and import it after installing the new system. Or you can export a specific area saved to update.zip as part of the upgrade package.
  • Step 310 When the hardware is compatible, the source mobile terminal transmits the system backup file to the target mobile terminal.
  • the Android upper application APK calls the Bluetooth or WIFI interface and functions to complete the file transfer. In addition to wireless interaction, the APK also needs to support reading and writing SD cards, compressing/decompressing zip files. If there is no system backup file in the source mobile terminal, the source mobile terminal backs up the system to generate a system backup file. The following describes the process of the overall backup of the source mobile terminal and the backup file format.
  • FIG. 6 is a schematic structural diagram of a system backup package according to an embodiment of the present invention. As shown in Figure 6, the combined file format of each binary partition is as follows:
  • the starting address for example, the length is 4 bytes
  • the length of the data for example, the length is 4 bytes
  • check value CHECKSUM for example, the length is 4 bytes
  • Step 320 Perform system upgrade on the target terminal according to the system backup file, including two situations, one is to install the obtained system backup file to perform system update; the other is to not directly install the system backup file, directly start the system. System backup file.
  • the specific steps to install a new system from the backup zip file include:
  • Initsd loads the modem's protocol stack module MODEM Firmware from the zip and then loads recovery.img from zip, where recovery, img is a dedicated module for Android system update, which can integrate multiple upgrade modules, so You can enter the "Google OTA Upgrade” mode, which is compatible with OTA upgrades, and upgrades the Android system related partitions and modem related partitions.
  • the mobile communication terminal of the embodiment of the present invention can be installed without any installation, and directly loads the MODEM Firmware and B Android system.
  • the following is an example of the Qualcomm MSM7x25 platform.
  • FIG. 7 is a normal startup process of a mobile communication terminal according to an embodiment of the present invention.
  • mARM is the modem side system
  • aARM is the android side system, except PBL (Primary BootLoader, the first boot program) is the chip comes with (for booting), the other is the name of each partition, where Kernel is boot.img
  • PBL Primary BootLoader, the first boot program
  • Kernel is boot.img
  • the main part, Kernel is the Android operating system kernel, including the operating system time slice scheduling, memory management, hardware drivers and other core work modules, boot.img also contains the ramdisk root directory file system.
  • FIG. 8 is a diagram showing an installation-free startup process of a mobile communication terminal according to an embodiment of the present invention.
  • each partition is on Nand Flash
  • mARM is modem side system
  • aARM is android side system
  • PBL is chip self-contained
  • QCSBL is chip self-contained
  • OEMSBL is the partition that must be on mobile phone NAND FLASH, just like BIOS on motherboard with PC (Basic Input Output System, firmware; other files or directories in the SD card.
  • BIOS Basic Input Output System, firmware; other files or directories in the SD card.
  • Appsboot is the loading boot module for Android
  • Load MODEM Firmware from the zip file to the appropriate location in memory and notify OEMSBL through the shared memory setting flag (OEMSBL) Need to poll the flag), let it jump directly to the entrance of the MODEM Firmware.
  • OEMSBL shared memory setting flag
  • Bootimg's root directory file system Ramdisk (memory disk, containing the user space data that needs to be set up after the kernel is initialized and the user space program that needs to be run) needs to be modified to fit the full Android System loaded from the zip file. Reading SD cards is relatively straightforward for initsd. Specific methods for modifying boot.img include:
  • VOLD Volume Daemon
  • the void program exists in the system, not in boot.img. That is, the boot.img mounts the SD card before loading the system, so that the system backup file on the SD card can be read and parsed.
  • VOLD is Android's default device management tool, which runs as a daemon. It manages device files in the /dev directory by listening to uevent events issued by the kernel. It works in user space.
  • Fuse-zip is based on the user-space file system follow extension. The latest version has been added to read and write zip format files.
  • the user space file system fuse is a loadable kernel module on a UNIX-like system platform, allowing non-privileged users to create a full-featured file system without recompiling the kernel.
  • the Fuse module only provides the access port of the kernel module, and its own The main implementation code is in user space. If you do not use the fose-zip file system, you can also use it directly.
  • the system partition file is extracted to a directory in the SD card and associated with the /system directory of the root file system so that the system can read and start android.
  • User data userdata partition which can be used in the tmpfs file system (a memory-based file system) where files are copied to the memory, or extracted from the zip file to the SD card.
  • MIBIB Multi-Image Boot Information Block
  • QCSBL QCSBL
  • OEMSBL OTP (One-time Password, Dynamic Password)
  • OTP is related to upgrade verification and is stored in the OEMINFO partition.
  • the OEMSBL has the ability to read the initsd (appsboot.mbn) file from the SD card and load it into memory.
  • initsd appsboot.mbn
  • MIBIB, QCSBL, OEMSBL, OTP will not affect the future upgrade even if it is not updated, which reduces the risk of system upgrade failure.
  • the initsd file supports zip files and parses them, supports all partition upgrades, supports SD card reading and writing, and can load MODEM Firmware Boot.img or Recovery. imgo as needed.
  • Step 330 Update a kernel driver of the target mobile terminal.
  • the kernel driver is divided into code and configuration data, the code is relatively fixed, the configuration data can be left and right code to go to different branches, the configuration data contains data similar to the script information, and the kernel module, that is, the SysData Module is specifically responsible for the configuration data during initialization.
  • the parsing installation in turn, can create a collection of many small block executables, and respectively associated with existing functions, thus changing the function of the original driver.
  • Configuration data can be imported from the user space when the kernel is running, or exported from the kernel. Please refer to Figure 3B again.
  • the configuration data When the configuration data is imported into SysData, the configuration data includes: At which processing point, which sub-processes are called, and which parameters are passed. Multiple processing points need to be stored in SysData using a linked list. A processing point can contain multiple sub-processing, which needs to be saved using a sub-linked list. Therefore, a mapping table needs to be established to implement the conversion.
  • the contents of the mapping table include: the processing point serial number corresponds to the function name and the first modification point; the sub processing serial number corresponds to the sub processing name.
  • SysData There are functions and variables to be called, so that the script information can be written. Of course, in order to have more functions, SysData needs to expand its own sub-function library and be able to parse more syntax.
  • the SYSDATA module matches all the sub-processes and parameters contained in the processing point according to the parameters (processing points) passed in the driver code, matches the corresponding processing points in the linked list, and then calls the sub-processing functions in turn, and passes in the parameters.
  • FIG. 9 is a flow chart showing the interaction between the driver module and the system data management module in the internal drive of the mobile communication terminal according to the embodiment of the present invention. As shown in Figure 9, the process includes the following steps:
  • Step 400 The SYSDATA module converts the driver configuration data into a configuration data link table according to the mapping table.
  • Step 402 The driving module calls the SysData() main function, and transmits the function name and the processing point number to the SYSDATA module.
  • the Driver_initO driver initialization function calls the SysDataQ main function, passing the function name and the modification point number to the SYSDATA module.
  • Step 404 The SYSDATA module converts the processing parameter sequence number according to the input parameter, and searches for a corresponding node in the configuration data link table. For example, the SYSDATA module finds a matching processing point 1 in the configuration data link table based on the passed function name and processing point number.
  • Step 406 The SYSDATA module calls the corresponding sub-processing function in the sub-processing function library according to the matched processing point information, and passes the parameter.
  • the processing to the processing point 1 the processing unit 1 corresponding sub-processing function number and parameter information are: Sub_Indexl, Paraml; Sub_Index2, Param2. So, call Subl ( ) and Sub2 ( ) in the subfunction, pass Paraml to Subl ( ), and pass Param2 to Sub2 ( ).
  • an update to the kernel driver is implemented.
  • An advantage of embodiments of the present invention is that an update to the kernel driver is implemented.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种移动通信终端间进行系统升级的方法、 系统及终端 技术领域 本发明涉及通信领域， 具体地涉及一种移动通信终端间进行系统升级的方法、 系统 及终端。 背景技术 图 1 为现有技术的无线升级的示意图。 无线升级一般是通过 OTA ( Over-the-Air Technology, 空中下载技术） 方式， 需要从运营商的升级服务器下载升级包到手机缓存 cache分区或 SD卡 （Secure Digital Memory Card, 安全数码卡） ， 再启动安装， 考虑到下 载过程的资费， 升级包应尽量小， 所以一般使用差分方式。 但是， OTA方式升级过程仍 然存在变数， 有可能是未发现的 Bug或升级时的断电。
在现有技术中， PC上已有成熟的 Linux LiveCD (直接引导为可用系统） 的方案， 例 如 UBUNTU (—个以桌面应用为主的 Linux操作系统） ， FEDORA (—种 Linux操作系 统） 都有 LiveCD的发行版本。 PC上也有将硬盘上的 C盘即系统盘， Ghost备份为一个文 件， 并能恢复的工具。 此外， 有些 Android智能手机具有通过恢复 recovery菜单， 将 android系统进行备份 /恢复的功能。 图 1A为现有技术备份 /恢复 Android系统的过程示意 图。 在图 1A中， 虚线框表示备份 /恢复的内容， 虚线箭头表示备份 /恢复的操作。
发明人在实现本发明的过程中发现， 现有技术至少存在以下不足： 现有技术的升级 方法依赖于专业的升级服务器， 升级不太方便， 不利于用户之间交换或更新系统。 而 且， 现有技术的升级方法没有考虑写入待手机的系统升级文件是否与手机的硬件版本兼 容， 这样存在升级失败的风险， 一旦升级失败将导致手机的功能无法正常使用， 现有技 术的升级方法在安全性方面也存在不足。 发明内容 本发明的目的在于， 提供一种移动终端间进行系统升级的方法、 系统及终端， 使着 移动终端的升级更加方便和安全， 不再依赖于专业的运营商升级服务器， 同时提高升级 成功率， 降低移动终端升级失败引起的功能异常的风险。
为达上述目的， 一方面， 本发明实施例提供了一种移动通信终端间进行系统升级的 方法， 所述方法包括： 目标移动终端判断与源移动终端是否硬件兼容； 当双方硬件兼容 时， 目标移动终端通过无线网络获取源移动终端传送的系统备份文件； 目标移动终端根据 所述系统备份文件进行系统升级。
为达上述目的， 另一方面， 本发明实施例提供了一种移动通信终端， 包括： 无线通 信单元， 用于与提供系统备份文件的源移动终端建立无线连接， 并获取源移动终端的硬 件信息； 硬件兼容判断单元， 用于根据所述源移动终端的硬件信息， 判断是否与源移动终 端硬件兼容； 当硬件兼容时触发所述无线通信单元从所述源移动终端获取系统备份文件； 系统升级单元， 用于根据所述系统备份文件进行系统升级。
为达上述目的， 又一方面， 本发明实施例提供了一种移动通信终端间进行系统升级 的系统， 包括： 目标移动终端， 用于获取源移动终端的硬件信息， 并根据所述源移动终端 的硬件信息， 判断是否与源移动终端硬件兼容； 当硬件兼容时， 从所述源移动终端获取 系统备份文件； 并根据所述系统备份文件进行系统升级； 源移动终端， 与所述目标移动终 端无线连接， 用于向所述目标移动终端提供源移动终端的硬件信息和所述系统备份文 件。
本发明实施例提供的上述技术方案的优点在于， 手机之间通过无线网络可实现系统 升级， 不再依赖于升级服务器， 无需从升级服务器下载升级文件， 可以减轻升级服务器 的负担， 同时也有利于手机用户之间方便地交换各自的系统， 实现系统升级。 通过在升 级前判断双方的硬件是否兼容， 有利于保证升级的成功率。 本发明实施例可让用户有更 多方便的升级方式供选择， 而不是完全依赖运营商服务器或专业人士。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施例或现有 技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是本 发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为现有技术的无线升级的示意图；
图 1A为现有技术的备份 /恢复 Android系统的过程示意图；
图 2为本发明实施例移动通信终端间进行系统升级的系统结构示意图；
图 3为本发明实施例的一种移动通信终端的功能框图；
图 3 A为本发明实施例的另一种移动通信终端的功能框图；
图 3B为本发明实施例图 3A中内核驱动更新单元的细化功能框图； 图 4为本发明实施例的移动通信终端间进行系统升级的方法流程图；
图 5为本发明实施例作为一个举例的手机间升级系统的流程图；
图 6为本发明实施例的系统备份包的结构示意图；
图 7为本发明实施例的移动通信终端的正常启动过程；
图 8为本发明实施例的移动通信终端的免安装启动过程；
图 9为本发明实施例的移动通信终端的内驱中驱动模块与系统数据管理模块进行内核 更新的交互流程图。 具体实施方式 下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整 地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基 于本发明中的实施例， 本领域普通技术人员在没有做出创造性劳动前提下所获得的所有 其他实施例， 都属于本发明保护的范围。
在本发明实施例中， 用户移动通信终端例如手机能通过蓝牙或 WIFI得到另一部硬件 版本兼容的手机生成的系统备份文件， 并进行升级， 以完成系统的更新或免安装启动新 系统。 这个过程也可称为手机"克隆"。
图 2为本发明实施例移动通信终端间进行系统升级的系统结构示意图。 如图 2所示， 该系统包括：
目标移动终端， 用于获取源移动终端的硬件信息， 根据源移动终端的硬件信息， 判 断是否与源移动终端硬件兼容； 当硬件兼容时， 从该源移动终端获取系统备份文件； 并根 据上述系统备份文件进行系统升级；
源移动终端， 与所述目标移动终端无线连接， 用于向所述目标移动终端提供源移动 终端的硬件信息和上述系统备份文件。
蓝牙 （Bluetooth) 和 WIFI (Wireless Fidelity, 802.11b标准） 是一种手机间免费的通 讯方式， 其中 WIFI速度较块。 目标移动终端和源移动终端可通过上述短距离无线网络进 行连接并传送硬件信息和系统备份文件。
其中， 硬件信息可以包括： 硬件版本标识 BoardID、 子硬件版本号、 包含处理器信 息、 内存信息和网络类型在内的关键硬件信息、 驱动标识 DriverlD等。 其中网络类型包 括： CDMA ( Code Division Multiple Access , 码分多址） 、 WCDMA ( Wideband Code Division Multiple Access , 宽带码分多址） 、 TD-SCDMA ( Time Division-Synchronous Code Division Multiple Access, 时分同步的码分多址） 或 GSM (Global System for Mobile Communications, 全球移动通信系统） 等。
其中， 系统备份文件可以存储于 SD卡上， 或者存储于移动终端自身的备份区域内。 系统备份文件可以是对移动终端的整个系统的备份， 例如包括调制解调器 Modem的镜像 文件和操作系统镜像文件。 其中， Modem的镜像文件例如包括： Qcsbl (Qualcomm Secondary Bootloader, 高通的二次引导程序）、 Oemsbl (OEM Secondary Bootloader, 厂商 的二次引导程序） 、 MODEM Firmware (调制解调器固件， 即调制解调器的通信协议 栈） 、 OEMINFO (厂商信息） 等。 也可以只备份一部分， 例如只备份操作系统中的引导 程序、 操作系统内核、 恢复程序。 也可以进一步备份通信协议栈， 还可以进一步备份用 户配置数据。 上述操作系统可以包括： Android系统， Windows Mobile等。 上述源移动终 端和目标移动终端可以是双核的或具有更多处理器的移动通信终端。
本发明实施例， 两个移动终端通过蓝牙或 WIFI等无线通信网络， 进行系统升级更 新， 不再依赖于专业的运营商升级服务器或专业人士， 移动终端的升级更加方便； 通过 确认双方的硬件是否兼容， 并在兼容时传送系统备份文件进行系统升级， 有利于保证升 级的成功率， 降低了移动终端升级失败的风险， 使得期望系统升级的目标移动终端不会 因为升级失败而无法正常使用。
本发明实施例还提供了一种移动通信终端， 对应于上述目标移动终端。 图 3为本发明 实施例的移动通信终端的功能框图。 如图 3所示， 其包括： 无线通信单元 10， 用于与提供 系统备份文件的源移动终端建立无线连接， 并获取源移动终端的硬件信息； 硬件兼容判断 单元 12， 用于根据源移动终端的硬件信息， 判断是否与源移动终端硬件兼容； 当硬件兼容 时触发所述无线通信单元从该源移动终端获取系统备份文件； 系统升级单元 14， 用于根据 所述系统备份文件进行系统升级。 由于涉及到两个移动终端之间的数据交互， 在必要 时， 比如目标移动终端获取源移动终端的硬件信息时， 以及从源移动终端获取系统备份文 件时， 双方的交互需要用户操作确认。
可选地， 上述硬件信息包括： 硬件版本标识 BoardID, 硬件兼容判断单元 12还可以用 于当移动通信终端与源移动终端的 BoardID相同时， 确定双方硬件兼容。
可选地， 上述硬件信息还包括： 子硬件版本号， 硬件兼容判断单元 12还可以用于： 当 移动通信终端与该源移动终端的 BoardID不同且子硬件版本号相同时， 确定双方硬件兼 容。
可选地， 上述硬件信息还包括： 处理器信息、 内存信息和网络类型， 硬件兼容判断单 元 12可以具体用于： 当移动通信终端与源移动终端的 BoardlD和子硬件版本号均不同时， 进一步判断双方的处理器信息 （例如高通公司的 MSM7201A/MSM8255芯片， MARVELL 公司的 PXA320芯片） 、 内存信息 （例如三星 Samsung的 NAND FLASH型号 KA524GACB- A050, 现代 hynix的 NAND FLASH型号 H8BCS0UN0MCR-4EM ) 和网络类型是否相同， 如不同， 则确定双方硬件不兼容。
可选地， 上述硬件信息还包括： 驱动标识 DriverlD, 硬件兼容判断单元 12可以具体用 于： 当移动通信终端与源移动终端的 BoardlD和子硬件版本号均不同， 且双方的处理器信 息、 内存信息和网络类型相同时， 进一步判断双方的 DriverlD是否相同， 如相同， 则确定 双方硬件兼容。
或者， 硬件兼容判断单元 12还可以用于当自身的 DriverlD与源移动终端的 DriverlD不 同时， 判断自身的 DriverlD是否存在于源移动终端同类硬件的 DriverlD构成的集合中， 如 是， 则确定双方的驱动兼容， 也即满足硬件兼容。 例如， 对于 T-Flash卡这一种硬件外设 的接口的插拔检测处理， 有中断和轮询两种工作方式， 中断方式需要硬件上另外提供中 断引脚， 轮询则不需要， 因此对于这同一种硬件外设接口就需要两种软件驱动： DriverlDlOl和 DriverID102， 当期望升级的目标移动通信终端的 T-Flash卡运行的软件驱动 为 DriverID101， 而源移动终端正在使用 DriverID102， 但源移动终端的用户数据存储空间 有 DriverlDlOl的配置数据， 该配置数据可以被装载运行， 这样该目标移动通信终端与源 移动终端的 T-Flash卡接口仍是兼容的。
具体地， 系统升级单元 14， 具体用于安装获取的所述系统备份文件， 以进行系统更 新； 或者， 不安装所述系统备份文件， 直接启动所述系统备份文件。 不安装而直接从系 统备份文件中启动系统的方式， 可以保证安全性。
图 3A为本发明实施例的另一种移动通信终端的功能框图。 如图 3A所示， 该移动通 信终端进一步包括： 内核驱动更新单元， 用于根据包含于所述系统备份文件内的驱动配 置数据， 对该移动通信终端的操作系统的内核驱动进行更新。
图 3B为本发明实施例图 3A中内核驱动更新单元的细化功能框图。 如图 3B所示， 该 内核驱动更新单元 16具体包括：
驱动配置数据模块 162， 用于获取驱动配置数据； 例如从携带系统备份文件的升级包 中获取， 或者如果该系统备份文件已被安装时， 从用户空间获取。
Sys文件系统模块 164， 用于将所述驱动配置数据导入目标移动通信终端的操作系统的 内核； 或者， 还用于将内核驱动的配置数据导出进行保存。 系统数据管理模块 166， 用于将 Sys文件系统模块导入的所述驱动配置数据映射成配置 数据链表， 所述配置数据链表包括： 处理点序号， 以及与所述处理点序号对应的子处理 函数编号和子处理函数的参数； 当需要更新内核驱动时， 根据处理点序号在所述配置数 据链表中搜索到与所述处理点序号相对应的处理点； 根据搜索到的处理点和所述配置数 据链表， 获得所述处理点对应的子处理函数编号和子处理函数的参数； 调用子处理函数 库中与所述子处理函数编号对应的子处理函数， 并传入所述子处理函数的参数以更新内 核驱动；
驱动模块 168， 用于使所述系统数据管理模块进行内核驱动更新， 向所述系统数据管 理模块传送处理点序号。
本发明实施例的优点在于： 1、 可以减轻升级服务器的负担； 2、 利用免费的通讯方 式， 实现手机系统在用户手机间方便安全的转移； 3、 备份的文件， 可直接载入系统， 免 安装， 是最安全的升级方式； 4、 实现了对内核驱动的更新。
本发明实施例还提供了一种移动通信终端间进行系统升级的方法。 图 4为本发明实施 例的移动通信终端间进行系统升级的方法流程图， 如图 4所示， 该方法包括：
步骤 200、 目标移动终端判断与源移动终端是否硬件兼容；
步骤 210、 当双方硬件兼容时， 目标移动终端通过无线网络获取源移动终端传送的系统 备份文件；
步骤 220、 目标移动终端根据所述系统备份文件进行系统升级。
步骤 200具体可包括： 目标移动终端判断与源移动终端是否具有相同的硬件版本标识 BoardID, 如是， 则确定双方硬件兼容。
进一步地， 当目标移动终端判断与源移动终端的硬件版本标识 BoardID不同时， 目标 移动终端进一步判断双方的子硬件版本号是否相同， 如相同则确定双方硬件兼容。
进一步地， 当目标移动终端判断与源移动终端的子硬件版本号不同时， 目标移动终 端还判断判断双方的处理器、 内存和网络类型是否相同， 如不同， 则确定双方硬件不兼 容。
进一步地， 当目标移动终端判断与源移动终端的处理器、 内存和网络类型相同时， 目标移动终端还判断双方的驱动标识 DriverlD是否相同， 当相同时， 确定双方驱动兼容及 硬件兼容。 或者， 进一步判断目标移动终端的软件驱动标识是否包含于源移动终端的驱 动标识构成的集合中， 如是， 则确定目标移动终端与源移动终端的驱动兼容， 否则， 驱 动不兼容。 或者， 目标移动终端获取源移动终端的包含所有外设的 DriverlD的列表， 并与 自身的包含所有外设的 DriverlD的列表进行比较， 当双方每一外设的 DriverlD都一致时， 确定目标移动终端与源移动终端之间是驱动兼容。
可选地， 图 4所示方法还包括： 在目标移动终端的人机界面上显示目标移动终端与源 移动终端间的硬件兼容情况报告或者硬件兼容指数。 该硬件兼容情况报告可以包括： 双 方的 BoardID相同， 硬件完全兼容； 双方的 BoardID不同但子硬件版本号相同， 硬件基本 兼容； 双方的 B0ardID、 子硬件版本号、 CPU、 内存及网络类型均不相同， 硬件不兼容； 双方的 BoardID和子硬件版本号不同， 双方的、 CPU、 内存及网络类型相同且双方的驱动 兼容， 硬件基本兼容； 双方的 BoardID和子硬件版本号不同， 双方的 CPU、 内存及网络类 型相同且双方的驱动不兼容， 则硬件不兼容。 可选地， 对于硬件兼容的情况， 分配硬件 兼容指数 100%， 对于硬件基本兼容的情况， 分配硬件兼容指数 60%， 对于硬件不兼容的 情况， 分配硬件兼容指数 30%。
具体地， 步骤 200的具体过程包括： 目标移动终端安装获取的上述系统备份文件， 以 进行系统更新； 或者， 目标移动终端不安装上述系统备份文件， 直接启动上述系统备份 文件。
可选地， 上述系统备份文件包括： 系统启动引导文件、 操作系统内核和操作系统。 此外， 系统备份文件还可以进一步包括： 通信协议栈和 /或用户配置数据。 其中用户配置 数据可用于对移动通信终端的操作系统的内核驱动进行更新。
可选地， 该方法还包括： 将目标移动终端与源移动终端之间不兼容的驱动对应的文 件导出并保存。
进一步地， 图 4所示方法还可以进一步如下步骤： 获取驱动配置数据； 将所述驱动配 置数据导入目标移动通信终端的操作系统的内核； 将所述驱动配置数据映射成配置数据 链表， 所述配置数据链表包括： 处理点序号， 以及与所述处理点序号对应的子处理函数 编号和子处理函数的参数； 当需要更新内核驱动时， 根据处理点序号在所述配置数据链 表中搜索到与所述处理点序号相对应的处理点； 根据搜索到的处理点和所述配置数据链 表， 获得所述处理点对应的子处理函数编号； 调用子处理函数库中与所述子处理函数编 号对应的子处理函数， 并传入所述子处理函数的参数以更新内核驱动。
本发明实施例提供的移动通信终端间进行系统升级的方法， 具有如下有益技术效 果-
1、 可以减轻升级服务器的负担。
2、 可以利用免费的通讯方式， 实现手机系统在用户手机间方便安全的转移。 3、 备份的文件， 可直接载入系统， 免安装， 是更为安全的升级方式。
以下通过举例进一步详细说明本发明实施例的技术方案。 图 5为本发明实施例作为一 个举例的手机间升级系统的流程图。 如图 5所示， 该流程包括如下步骤：
步骤 300、 通过移动终端之间交互， 来确认目标移动终端与源移动终端的硬件是否兼 容。 根据硬件兼容的情况， 在移动通信终端的图形用户界面上 （UI， User Interface) 显示 指示兼容程度的指数值， 以供用户决定是否进行升级包的传输和升级。 上述过程包括如下 步骤：
步骤 1、 负责源终端和目标终端之间交互的模块， 首先各自通过读取 /proc文件系统 得到厂家统一规划的硬件版本标识 BoardID,然后比较双方的 BoardID是否相同， 如果相 同，则判断双方的硬件完全相同， 即兼容指数为 100%， 该兼容指标可以呈现给用户参 考。 如果不相同， 则进一步判断子硬件版本号是否相同， 由于 BoardID还包括主版本号 和子版本号， 如果主版本号相同但子版本号不同， 则是基本兼容， 或者说是不完全兼 容。
步骤 2、 通过读取 /proc文件系统，得到双方的包括 CPU、 内存 RAM/ROM、 网络类型 CDMA/WCDMA/TD-SCDMA/GSM 在内的关键信息。 判断双方的 CPU、 内存 RAM/ROM 网络类型 CDMA/WCDMA/TD-SCDMA/GSM是否相同， 如相同则基本兼容, 即系统是可以启动的， 不会变成 "砖头" ， 显示给用户的兼容指数例如为 60%。 还需要 进一步判断其它驱动信息是否相同； 当这些信息不相同时， 则判断双方硬件不兼容， 如 兼容指数为 30%。
步骤 3、 通过 sysfs文件系统 /sys/devices/platform/查看其它驱动的信息，即厂家统一规 划的软件驱动标识 DriverID。 其中， 该 sysfs文件系统类似于 Windows的注册表， 是导出 内核内部对象及其属性和对象之间的相互关系的文件系统， 它把连接在系统上的设备、 总线和驱动程序等组织成为一个分级的文件， 内核启动时依靠它挂载根分区， 禁用 sysfs 后需要在内核引导参数中使用设备号指定根分区。 每个驱动在 sysfs文件系统中都有相应 处理点， 并且驱动代码要支持读取每个驱动配置信息。 如果 DriverlD相同， 则驱动兼 容， 如不同可再查看需升级手机的默认 DriverlD是否存在于提供升级包的源手机的同类 硬件设备的 DriverlD集合中， 如存在也判断为驱动兼容。
步骤 4、 如某个 DriverlD不兼容， 可以先导出配置信息单独保存， 安装完新系统后再 将其导入。 或者可导出保存到 update.zip的特定区域成为升级包的一部分。
步骤 310、 当硬件兼容时， 源移动终端向目标移动终端传送系统备份文件。 具体地， Android上层应用程序 APK调用蓝牙或者 WIFI的接口和功能以完成文件传输。 APK除了 通过无线交互， 还需支持读写 SD卡， 压缩 /解压 zip文件。 如果源移动终端中没有系统备 份文件， 则源移动终端对系统进行备份， 生成系统备份文件。 以下说明源移动终端进行 整体备份的过程和备份文件格式。
在源移动终端中， Android上层代码调用 MTD (memory technology device, 内存技术 设备） 驱动， MTD在硬件和文件系统之间提供了一个抽象的接口， 将二进制分区读出， 各分区合并为一个文件保存在压缩 zip文件中。 文件系统的分区一般以文件方式读出， 保 存在 zip文件中的同名文件夹下。 备份文件格式类似 google OTA zip文件升级包。 图 6为 本发明实施例的系统备份包的结构示意图。 如图 6所示， 各二进制分区合并后的文件格式 如下：
a)文件头， 包含各分区的始末位置和版本控制信息；
b)起始地址， 例如长度为 4字节；
c)数据长度， 例如长度为 4字节；
d)校验值 CHECKSUM, 例如长度为 4字节；
e)数据， 例如为 1个 Block。
将 Appsbootmbn改名为 initsd ( init from sdcard, 初始化外部介质并载入系统的模 块） ， 并单独以一个文件打包在 zip文件中， 启动升级系统时， 需要先把 initsd文件解压 到 SD卡根目录下， 整个备份文件以 zip方式压缩保存在用户区或 SD卡。
步骤 320、 根据系统备份文件对目标终端进行系统升级， 包括两种情况， 一种是安装 获取的系统备份文件， 以进行系统更新； 另一种是， 不安装所述系统备份文件， 直接启 动所述系统备份文件。
其中， 从备份的 zip文件安装新系统的具体步骤包括：
OEMSBL载入 initsd文件后， 可对所有二进制分区进行升级。
initsd从 zip中加载调制解调器的协议栈模块 MODEM Firmware (调制解调器固件） 再从 zip加载 recovery.img, 其中， recovery, img是 Android系统用于系统更新的专用模 块，其可以集成多种升级模块， 这样就可进入 "Google OTA升级"模式， 该 zip文件与 OTA升级兼容， 对 Android系统相关分区以及调制解调器相关分区进行升级。
本发明实施例的移动通信终端可以免安装， 直接加载 MODEM Firmware禾 B Android 系统。 下面以高通 MSM7x25平台为例进行说明，
图 7为本发明实施例的移动通信终端的正常启动过程。 其中， 各分区在 Nand Flash 上， mARM为 modem侧系统， aARM为 android侧系统， 除 PBL (Primary BootLoader, 第一个引导程序） 为芯片自带 （用于启动引导） ， 其他为各分区名称，其中 Kernel为 boot.img的主要部分， Kernel是 Android的操作系统内核， 包括操作系统时间片调度， 内 存管理， 硬件驱动等核心工作模块， boot.img还包含了 ramdisk根目录文件系统。
图 8为本发明实施例的移动通信终端的免安装启动过程。 其中， 各分区在 Nand Flash 上， mARM为 modem侧系统， aARM为 android侧系统， PBL为芯片自带， QCSBL, OEMSBL为手机 NAND FLASH上必须具有的分区， 就像 PC上主板带的 BIOS (Basic Input Output System, 基本输入输出系统） 固件；其它为 SD卡中文件或目录，当然这些部 分经过安装， 就会与手机成为一部分， 但其不是安装前手机启动所必须的。
如图 8所示， Initsd (经过功能增强的 Appsboot, Appsboot是 Android系统的载入引 导模块） 从 zip文件中加载 MODEM Firmware到内存中相应位置， 并通过共享内存设置 标志， 通知 OEMSBL ( OEMSBL这阶段需要轮询该标志） ， 让其直接跳转 Jump 到 MODEM Firmware的入口处。
然后 initsd就可以顺利加载 boot.img ( linux Kernel ) ， 因为是 MSM7x25 平台， MODEM Firmware加载是 Kernel启动的必要条件。
bootimg的根目录文件系统 Ramdisk (内存盘，包含内核初始化后， 首先需要设置的用 户空间数据和需要运行的用户空间程序)需要修改， 以适应从 zip 文件中加载完整的 Android System。 读取 SD卡对于 initsd是相对简单的， 对于 boot.img的修改的具体方法包 括：
1 ) 在 boot.img的根目录文件系统 Ramdisk中增加 VOLD (Volume Daemon, 磁盘设 备守护神)等读写 SD卡必要的应用， 目前 void程序存在与 system中， 而不在 boot.img 中。 即 boot.img加载 system前就要挂载 （mount) SD卡， 这样才能读取 SD卡上的系统 备份文件并解析。 其中， VOLD是 Android预设的设备管理工具， 以守护进程的形式运 行， 通过监听内核发出的 uevent事件来管理 /dev 目录下的设备文件， 其工作在用户空间
(user space) ， 而不是内核空间 (kernel space) 。
2) 还需要集成 fuse-zip文件系统。 fuse-zip是基于用户空间的文件系统 fose扩展的， 最新版本已加入了读写 zip格式文件的功能。 其中， 用户空间文件系统 fuse作为类 UNIX 系统平台上可加载的内核模块， 允许非特权用户创建功能完备的文件系统， 而不需要重 新编译内核， Fuse模块仅仅提供 kernel模块的接入口， 而本身的主要实现代码位于用户 空间中。 如果不使用 fose-zip文件系统， 也直接解压使用。 system分区的文件， 解压到 SD卡 中的某个目录内， 并和根文件系统的 /system 目录相关联， 以便系统读取和启动 android。 用户数据 userdata分区， 可以将其中文件拷贝到内存的 tmpfs文件系统 （一种基于内存的 文件系统） 中使用， 或从 zip文件中解压到 SD卡后使用。
需要说明的是， 手机上 （以 MSM7x25平台为例） 至少应存在： MIBIB (Multi-Image Boot Information Block, 多分区启动信息模块） ， QCSBL , OEMSBL, OTP ( One-time Password, 动态口令） ， 其中 OTP是升级验证相关， 存于 OEMINFO分区， 这四个分区 占用 10M左右，类似 PC的 BIOS。
OEMSBL具备从 SD卡读取 initsd (appsboot.mbn) 文件， 并载入内存的功能。 这样 不同版本升级只需改变 initsd, 其中 initsd可事先保存在 system分区， 而 MIBIB、 QCSBL, OEMSBL , OTP 即使不更新也不会影响今后升级， 降低了系统升级失败的风 险。 当然也支持更新前三个部分。 initsd文件支持 zip文件并解析其中文件， 支持所有分 区的升级， 支持 SD 卡的读写； 能根据需要载入 MODEM Firmware Boot.img 或 Recovery. imgo
步骤 330、 对目标移动终端的内核驱动进行更新。
本发明实施例将内核驱动分成代码和配置数据，代码相对固定的， 配置数据可以左右 代码走不同分支， 配置数据中包含类似脚本信息的数据， 增加内核模块即 SysData Module 专门负责初始化时对配置数据的解析安装，进而可以建立许多小块执行体的集合， 并分别 与现有函数关联， 这样就改变了原有驱动的功能。 配置数据可以在内核运行时从用户空 间导入安装， 也可以从内核导出保存。 请再次参阅图 3B。
实现分 4部分：
1、 驱动代码中的修改， 在需修改的函数中插入 SysData (系统数据管理模块） 的统 一的接口函数， 要将 "— fimc— " (实际上是函数名称的字符串） 作为参数传入， 并将这 是该函数内的第几个处理点， 作为参数传入。 这样相当于注册了一个处理点。 一个处理 点包含的信息是， 具体函数名称和该函数中第几个修改点。
2、 配置数据导入 SysData时的转换， 配置数据包括： 在哪个处理点， 调用哪些子处 理， 传入哪些参数。 多个处理点在 SysData中需要使用链表来保存， 一个处理点可以包含 多项子处理， 需要使用子链表保存。 因此需要建立映射表来实现转换， 映射表的内容包 括： 处理点序号对应函数名称和第几修改点； 子处理序号对应子处理名。
3、 子处理函数库的建立， 对变量的赋值都可转化成对函数的调用。 SysData中对所 有需调用函数和变量进行了编号， 这样脚本信息的编写就有了依据， 当然为了功能更丰 富， SysData需扩充自己的子处理函数库， 以及能够解析更多的语法。
4、 SYSDATA模块根据驱动代码传入的参数 （处理点） ， 匹配到链表中的相应处理 点,得到处理点包含的所有子处理和参数， 然后依次调用子处理函数， 并传入参数。
下面配合附图举例说明：
图 9为本发明实施例的移动通信终端的内驱中驱动模块与系统数据管理模块进行内核 更新的交互流程图。 如图 9所示， 该流程包括如下步骤：
步骤 400、 SYSDATA模块根据映射表将驱动配置数据转换为配置数据链表。
步骤 402、 驱动模块调用 SysData()主函数， 向 SYSDATA模块传送函数名称和处理 点序号。 例如 Driver_initO驱动初始化函数调用 SysDataQ主函数， 向 SYSDATA模块传入 函数名称和修改点序号。
步骤 404、 SYSDATA模块根据传入的参数转换成处理点序号， 在配置数据链表中寻 找相应节点。 例如 SYSDATA模块根据传入的函数名称和处理点序号， 在配置数据链表 中找到了匹配的处理点 1。
步骤 406、 SYSDATA模块根据匹配到的处理点信息， 调用子处理函数库中的相应子 处理函数， 并传入参数。 例如匹配到处理点 1， 处理点 1对应的子处理函数编号和参数信 息分别为： Sub_Indexl， Paraml； Sub_Index2 , Param2。 于是， 在子函数中调用 Subl ( ) 和 Sub2 ( ) ， 并往 Subl ( ) 中传入 Paraml , 往 Sub2 ( ) 中传入 Param2。 至此， 实 现了对内核驱动的更新。
本发明实施例的优点在于， 实现了对内核驱动的更新。
以上实施例仅用以说明本发明实施例的技术方案， 而非对其限制； 尽管参照前述实 施例对本发明实施例进行了详细的说明， 本领域的普通技术人员应当理解： 其依然可以 对前述各实施例所记载的技术方案进行修改， 或者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技术方案的本质脱离本发明实施例各实施例技术方案 的精神和范围。

Claims

权利要求书
1、 一种移动通信终端间进行系统升级的方法， 其特征在于， 所述方法包括： 目标移动终端判断与源移动终端是否硬件兼容；
当双方硬件兼容时， 目标移动终端通过无线网络获取源移动终端传送的系统备份文 件；
目标移动终端根据所述系统备份文件进行系统升级。
2、 根据权利要求 1所述的方法， 其特征在于， 所述目标移动终端判断与源移动终端 是否硬件兼容包括： 目标移动终端判断与源移动终端是否具有相同的硬件版本标识 BoardID, 如是， 则确定双方硬件兼容。
3、 根据权利要求 2所述的方法， 其特征在于， 所述方法还包括： 当目标移动终端判 断与源移动终端的硬件版本标识 BoardID不同时， 目标移动终端还判断双方的子硬件版本 号是否相同， 如相同则确定双方硬件兼容。
4、 根据权利要求 3所述的方法， 其特征在于， 所述方法还包括： 当目标移动终端判 断与源移动终端的子硬件版本号不同时， 目标移动终端还判断判断双方的处理器、 内存 和网络类型是否相同， 如不同， 则确定双方硬件不兼容； 当目标移动终端判断与源移动 终端的处理器、 内存和网络类型相同时， 目标移动终端还判断双方的驱动标识 DriverlD是 否相同， 当相同时， 确定硬件兼容。
5、 根据权利要求 1-4中任一项所述的方法， 其特征在于， 所述方法还包括： 在目标移 动终端的人机界面上显示目标移动终端与源移动终端间的硬件兼容情况报告或者硬件兼 容指数。
6、 根据权利要求 1所述的方法， 其特征在于， 所述目标移动终端根据所述系统备份 文件进行系统升级包括： 目标移动终端安装获取的所述系统备份文件， 以进行系统更 新； 或者， 目标移动终端不安装所述系统备份文件， 直接启动所述系统备份文件。
7、 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括：
获取驱动配置数据；
将所述驱动配置数据导入目标移动通信终端的操作系统的内核；
将所述驱动配置数据映射成配置数据链表， 所述配置数据链表包括： 处理点序号， 以及与所述处理点序号对应的子处理函数编号和子处理函数的参数；
当需要更新内核驱动时， 根据处理点序号在所述配置数据链表中搜索到与所述处理 点序号相对应的处理点； 根据搜索到的处理点和所述配置数据链表， 获得所述处理点对应的子处理函数编号 和子处理函数的参数；
调用子处理函数库中与所述子处理函数编号对应的子处理函数， 并传入所述子处理 函数的参数以更新内核驱动。
8、 一种移动通信终端， 其特征在于， 包括：
无线通信单元， 用于与提供系统备份文件的源移动终端建立无线连接， 并获取源移 动终端的硬件信息；
硬件兼容判断单元， 用于根据所述源移动终端的硬件信息， 判断是否与源移动终端硬 件兼容； 当硬件兼容时触发所述无线通信单元从所述源移动终端获取系统备份文件； 系统升级单元， 用于根据所述系统备份文件进行系统升级。
9、 根据权利要求 8所述的移动通信终端， 其特征在于， 所述硬件信息包括： 硬件版 本标识 BoardID, 所述硬件兼容判断单元具体用于当所述移动通信终端与所述源移动终端 的 BoardID相同时， 确定双方硬件兼容。
10、 根据权利要求 9所述的移动通信终端， 其特征在于， 所述硬件信息还包括： 子硬 件版本号， 所述硬件兼容判断单元还用于： 当所述移动通信终端与所述源移动终端的 BoardID不同且子硬件版本号相同时， 确定双方硬件兼容。
11、 根据权利要求 10所述的移动通信终端， 其特征在于， 所述硬件信息还包括： 处理 器信息、 内存信息和网络类型， 所述硬件兼容判断单元还用于： 当所述移动通信终端与所 述源移动终端的 BoardID和子硬件版本号均不同时， 进一步判断双方的处理器信息、 内存 信息和网络类型是否相同， 如不同， 则确定双方硬件不兼容；
所述硬件信息还包括： 驱动标识 DriverlD,所述硬件兼容判断单元还用于： 当所述移 动通信终端与所述源移动终端的 BoardID和子硬件版本号均不同， 且双方的处理器信息、 内存信息和网络类型相同时， 进一步判断双方的 DriverlD是否相同， 如相同， 则确定双方 硬件兼容。
12、 根据权利要求 8所述的移动通信终端， 其特征在于， 所述系统升级单元， 具体用 于安装获取的所述系统备份文件， 以进行系统更新； 或者， 不安装所述系统备份文件， 直接启动所述系统备份文件。
13、 根据权利要求 8所述的移动通信终端， 其特征在于， 所述移动通信终端还包括： 内核驱动更新单元， 用于对所述移动通信终端的内核驱动进行更新； 所述内核驱动更新 单元包括： 驱动配置数据模块， 用于获取驱动配置数据；
Sys文件系统模块， 用于将所述驱动配置数据导入目标移动通信终端的操作系统的内 核；
系统数据管理模块， 用于将 Sys文件系统模块导入的所述驱动配置数据映射成配置数 据链表， 所述配置数据链表包括： 处理点序号， 以及与所述处理点序号对应的子处理函 数编号和子处理函数的参数； 当需要更新内核驱动时， 根据处理点序号在所述配置数据 链表中搜索到与所述处理点序号相对应的处理点； 根据搜索到的处理点和所述配置数据 链表， 获得所述处理点对应的子处理函数编号和子处理函数的参数； 调用子处理函数库 中与所述子处理函数编号对应的子处理函数， 并传入所述子处理函数的参数以更新内核 驱动；
驱动模块， 用于使所述系统数据管理模块进行内核驱动更新， 向所述系统数据管理 模块传送处理点序号。
14、 一种移动通信终端间进行系统升级的系统， 其特征在于， 包括：
目标移动终端， 用于获取源移动终端的硬件信息， 并根据所述源移动终端的硬件信 息， 判断是否与源移动终端硬件兼容； 当硬件兼容时， 从所述源移动终端获取系统备份 文件； 并根据所述系统备份文件进行系统升级；
源移动终端， 与所述目标移动终端无线连接， 用于向所述目标移动终端提供源移动 终端的硬件信息和所述系统备份文件。
PCT/CN2011/073643 2011-05-04 2011-05-04 一种移动通信终端间进行系统升级的方法、系统及终端 WO2011127845A2 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP11768456.3A EP2675110B1 (en) 2011-05-04 2011-05-04 Method, system and terminal for system update between mobile communication terminals
PCT/CN2011/073643 WO2011127845A2 (zh) 2011-05-04 2011-05-04 一种移动通信终端间进行系统升级的方法、系统及终端
CN201180000646.4A CN102232304B (zh) 2011-05-04 2011-05-04 一种移动通信终端间进行系统升级的方法、系统及终端
US14/070,818 US9301164B2 (en) 2011-05-04 2013-11-04 Method, system, and terminal for performing system update between mobile communication terminals

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/073643 WO2011127845A2 (zh) 2011-05-04 2011-05-04 一种移动通信终端间进行系统升级的方法、系统及终端

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/070,818 Continuation US9301164B2 (en) 2011-05-04 2013-11-04 Method, system, and terminal for performing system update between mobile communication terminals

Publications (2)

Publication Number Publication Date
WO2011127845A2 true WO2011127845A2 (zh) 2011-10-20
WO2011127845A3 WO2011127845A3 (zh) 2012-04-05

Family

ID=44799075

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/073643 WO2011127845A2 (zh) 2011-05-04 2011-05-04 一种移动通信终端间进行系统升级的方法、系统及终端

Country Status (4)

Country Link
US (1) US9301164B2 (zh)
EP (1) EP2675110B1 (zh)
CN (1) CN102232304B (zh)
WO (1) WO2011127845A2 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102662792A (zh) * 2012-03-01 2012-09-12 上海艾尚通讯科技有限公司 手机与电脑的数据备份方法及系统
CN102664929A (zh) * 2012-04-05 2012-09-12 福兴达科技实业（深圳）有限公司 移动终端及其管理大容量存储设备的方法

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5775177B2 (ja) 2011-09-14 2015-09-09 株式会社日立製作所 クローンファイル作成方法と、それを用いたファイルシステム
CN103186398A (zh) * 2011-12-31 2013-07-03 国民技术股份有限公司 读卡器升级装置及升级方法
JP5886099B2 (ja) * 2012-03-21 2016-03-16 日立オートモティブシステムズ株式会社 自動車用電子制御装置
CN102880495A (zh) * 2012-10-15 2013-01-16 华为终端有限公司 移动终端及其软件升级方法
CN102929676B (zh) * 2012-11-05 2016-05-11 深圳市信一网络有限公司 基于安卓操作系统终端设备的快速适配方法
CN103176822B (zh) * 2013-03-04 2016-08-31 广东欧珀移动通信有限公司 一种下载数据的控制方法及控制装置
CN103414772A (zh) * 2013-08-09 2013-11-27 百灵时代传媒集团有限公司 一种应用于移动设备的云更新资源的方法及装置
CN103533024A (zh) * 2013-09-17 2014-01-22 福州瑞芯微电子有限公司 一种移动设备上同步固件的方法
CN103500113B (zh) * 2013-10-12 2017-06-13 上海斐讯数据通信技术有限公司 一种移动终端外部设备兼容的方法及系统
CN103744687B (zh) * 2013-11-15 2017-01-25 曙光信息产业(北京)有限公司 输入/输出端口的访问方法和装置
CN104657161A (zh) * 2013-11-21 2015-05-27 中兴通讯股份有限公司 移动终端固件更新方法及装置
CN104699491A (zh) * 2013-12-06 2015-06-10 中兴通讯股份有限公司 一种应用程序的升级处理方法及终端设备
CN104714819B (zh) * 2013-12-16 2019-11-15 中兴通讯股份有限公司 文件系统升级包制作方法、升级方法及装置、终端
CN104780189A (zh) * 2014-01-13 2015-07-15 中兴通讯股份有限公司 一种软件升级方法及装置
US9575741B2 (en) * 2014-03-20 2017-02-21 Google Technology Holdings LLC Methods and devices for wireless device-to-device software upgrades
CN103955158B (zh) * 2014-04-15 2016-08-17 中国石油集团东方地球物理勘探有限责任公司 一种远程遥测终端控制器及系统启动方法
CN104065726B (zh) * 2014-06-25 2018-04-24 珠海市杰理科技股份有限公司 客户端数据更新方法及系统
CN104143067B (zh) * 2014-08-05 2017-02-15 广东欧珀移动通信有限公司 一种终端设备及软件共享机制的实现方法
CN105376732A (zh) * 2014-08-27 2016-03-02 中兴通讯股份有限公司 一种实现固件升级的方法和移动终端
KR102270129B1 (ko) * 2014-09-11 2021-06-28 삼성전자 주식회사 무선 제어 방법, 그 제어 장치 및 서버
US10367689B2 (en) * 2014-10-24 2019-07-30 Comscore, Inc. Monitoring internet usage on home networks of panelist users
CN104360884A (zh) * 2014-11-18 2015-02-18 久邦计算机技术（广州）有限公司 一种基于安卓系统的插件资源包加载方法
CN105792182A (zh) * 2014-12-18 2016-07-20 博雅网络游戏开发（深圳）有限公司 应用于移动设备的资源更新方法和系统
CN104484211B (zh) * 2014-12-29 2017-07-28 广东欧珀移动通信有限公司 共享镜像文件的方法及装置
CN104881335B (zh) * 2015-03-16 2019-06-18 Oppo广东移动通信有限公司 一种备份应用还原方法及终端
EP3200072B1 (en) * 2015-03-24 2019-08-14 Huawei Technologies Co., Ltd. Method for updating terminal system, terminal and system
CN105101162A (zh) * 2015-07-13 2015-11-25 广东欧珀移动通信有限公司 自动加载mbn的方法及装置
CN105045671B (zh) * 2015-08-17 2018-04-03 广东欧珀移动通信有限公司 一种智能终端的系统升级方法及装置
CN105049452B (zh) * 2015-08-25 2018-04-20 广东欧珀移动通信有限公司 资源下载方式的切换方法、装置及智能终端
CN105320548B (zh) * 2015-11-30 2019-02-15 小米科技有限责任公司 终端系统升级方法及装置
EP3441876B1 (en) * 2016-04-27 2023-02-15 Honor Device Co., Ltd. Patch upgrade-based file processing method and device, terminal, and storage medium
WO2018027442A1 (zh) * 2016-08-07 2018-02-15 李仁涛 一种蓝牙设备的无线升级方法、升级装置及蓝牙设备
CN106331097A (zh) * 2016-08-23 2017-01-11 广东欧珀移动通信有限公司 信息收发及同步方法、装置、终端和服务器
CN106658354B (zh) * 2016-09-14 2019-10-18 Oppo广东移动通信有限公司 一种数据传输方法及设备
CN108024002B (zh) * 2016-10-31 2021-05-07 成都卫士通信息产业股份有限公司 一种基于rom的双域手机系统的构建方法
CN106569869B (zh) * 2016-11-14 2019-04-19 平安科技（深圳）有限公司 插件化打包方法及装置
CN106791124B (zh) * 2016-12-27 2020-10-20 北京奇虎科技有限公司 移动终端的刷机方法和刷机装置
CN108279941B (zh) 2016-12-31 2021-06-15 阿里巴巴集团控股有限公司 一种应用程序的压缩方法和装置
CN107145308B (zh) * 2017-05-04 2021-06-22 惠州Tcl移动通信有限公司 移动终端、及其sd卡操作控制方法、系统、存储装置
CN108334369A (zh) * 2017-09-05 2018-07-27 深圳天珑无线科技有限公司 设备刷机方法、装置及非易失性计算机存储介质
CN108170450A (zh) * 2017-12-28 2018-06-15 北京远特科技股份有限公司 一种设备中系统固件的升级方法、装置及系统
US11449327B2 (en) * 2018-11-30 2022-09-20 Paccar Inc Error-resilient over-the-air software updates for vehicles
CN109739535B (zh) * 2018-12-28 2022-02-18 郑州云海信息技术有限公司 一种对产品进行驱动维护的方法和系统
CN109889588B (zh) * 2019-02-13 2021-10-29 中国银行股份有限公司 文件获取方法、装置、计算机设备和存储介质
CN110018999B (zh) * 2019-04-15 2023-07-11 深信服科技股份有限公司 一种文件管理方法、系统及电子设备和存储介质
CN112235849A (zh) * 2020-10-19 2021-01-15 展讯半导体(成都)有限公司 识别Wi-Fi热点类型的方法、系统、电子设备和介质
CN114205227A (zh) * 2021-12-10 2022-03-18 珠海格力电器股份有限公司 设备的同步方法和装置、存储介质、电子装置
CN117130826A (zh) * 2023-02-28 2023-11-28 荣耀终端有限公司 一种数据备份方法、电子设备、数据备份系统及存储介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1537491A1 (en) * 2002-09-11 2005-06-08 Nokia Corporation Method, device and system for automated synchronization between terminals
US7337311B2 (en) * 2003-11-18 2008-02-26 Giga-Byte Technology Co., Ltd. Method for controlling upgrade of firmware
WO2006000122A1 (fr) * 2004-06-23 2006-01-05 Zte Corporation Procede de mise en concordance de version sur systeme de communications mobiles
US9883019B2 (en) * 2005-04-28 2018-01-30 Kyocera Corporation Mobile communication terminal and software update method
US8010971B2 (en) * 2005-06-29 2011-08-30 Fmr Llc Voice over internet protocol remote upgrading
US20070168571A1 (en) * 2005-11-02 2007-07-19 Dell Products L.P. System and method for automatic enforcement of firmware revisions in SCSI/SAS/FC systems
CN100371898C (zh) * 2006-03-28 2008-02-27 华为技术有限公司 一种移动终端软件自动加载的方法
CN101163055A (zh) * 2007-11-21 2008-04-16 浪潮电子信息产业股份有限公司 一种自动探测服务器硬件信息的方法
US8561052B2 (en) * 2008-12-08 2013-10-15 Harris Corporation Communications device with a plurality of processors and compatibility synchronization module for processor upgrades and related method
WO2010141922A1 (en) * 2009-06-04 2010-12-09 Abbott Diabetes Care Inc. Method and system for updating a medical device
CN101711026B (zh) * 2009-12-11 2013-06-05 中兴通讯股份有限公司 一种移动终端间软件版本的升级方法及升级系统
CN101867694A (zh) * 2010-05-21 2010-10-20 中兴通讯股份有限公司 交互式网络电视iptv机顶盒的升级方法及系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None
See also references of EP2675110A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102662792A (zh) * 2012-03-01 2012-09-12 上海艾尚通讯科技有限公司 手机与电脑的数据备份方法及系统
CN102664929A (zh) * 2012-04-05 2012-09-12 福兴达科技实业（深圳）有限公司 移动终端及其管理大容量存储设备的方法

Also Published As

Publication number Publication date
CN102232304B (zh) 2014-01-08
CN102232304A (zh) 2011-11-02
EP2675110B1 (en) 2015-09-02
US20140057620A1 (en) 2014-02-27
EP2675110A4 (en) 2014-04-23
US9301164B2 (en) 2016-03-29
WO2011127845A3 (zh) 2012-04-05
EP2675110A2 (en) 2013-12-18

Similar Documents

Publication Publication Date Title
WO2011127845A2 (zh) 一种移动通信终端间进行系统升级的方法、系统及终端
EP3441876B1 (en) Patch upgrade-based file processing method and device, terminal, and storage medium
US10866801B1 (en) Non-destructive update of discrete components of firmware
EP1983432A1 (en) Booting system, boot program, and method therefor
US20100132042A1 (en) Method for upgrading antivirus software and terminal and system thereof
WO2014194865A1 (zh) 一种固件升级方法、装置及通信设备
WO2015139246A1 (zh) 一种应用数据同步的方法及装置
WO2015074435A1 (zh) 移动终端固件更新方法及装置
WO2023087696A1 (zh) 通信模组及其外部接口配置方法、配置装置和存储介质
US10078532B2 (en) Resource management method and device for terminal system among multiple operating systems
WO2022143126A1 (zh) 应用的安全性分析方法、装置、设备及存储介质
CN108234174B (zh) 虚拟网络功能的管理方法和装置
CN113094064A (zh) 网关软件模块升级方法、装置、设备及存储介质
WO2023198056A1 (zh) 嵌入式设备固件更新方法以及嵌入式设备
CN114816491A (zh) 用于多系统移动终端的系统升级方法、装置及终端
CN115357295B (zh) 系统回退方法、设备及存储介质
WO2013004175A1 (zh) 一种电子设备的软件升级方法及装置
CN107332589A (zh) 一种基于蓝牙的固件升级装置
CN116260718A (zh) 一种物联网设备固件升级方法及系统
US20230350738A1 (en) Method for Reusing Shared Library and Electronic Device
CN104007979A (zh) 一种Bootloader层驱动无线网络的方法
JP4063573B2 (ja) デバイスドライバの組み込み・実行方式、組み込み・実行方法、及びプログラム
CN111338667A (zh) 一种应用程序app的升级方法与升级装置
WO2023030142A1 (zh) 应用程序升级方法、电子设备、芯片及可读存储介质
CN117707630B (zh) 分区切换过程中的中断处理方法、设备及存储介质

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180000646.4

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11768456

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2011768456

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE