A software updating method and system based on an ARM server

Abstract

The application discloses a software updating method and system based on an ARM server, and comprises the following steps: a request access source device connection verification request is sent by an application device; the source device analyzes the connection verification information, and if the connection request passes the verification, the source device and the application device establish a continuous communication preparation; the source device receives an updating request of the application device, and transmits the source device software information to the application device; the application device compares the source device software information with the self software information, obtains an updating list, and transmits the updating list to the source device; the source device analyzes the type of the software in the updating list; the source device selects a corresponding updating mode according to the type, transmits the updating file to the application device; the application device receives the software updating file and completes the software updating; if an exception occurs, a search program is started, when the search is successful, the gray degree is returned; when the search fails, the search program reports an exception, the efficiency of the software updating is improved, and the demand of users for the gray degree updating is met.

Description

Technical Field

[0001] This invention belongs to the field of software update technology, and specifically relates to a software update method and system based on an ARM server. Background Technology

[0002] In the current mobile app industry, gaming experiences are evolving towards immersive experiences and high computing power. However, mobile phones tend to drain batteries quickly and overheat, and apps are prone to lag and crashes. The processing power of traditional mobile phone processors cannot meet the demands of high-computation scenarios. Insufficient screen update responsiveness can also lead to inaccurate operations, impacting the user experience. Therefore, Android emulators, which provide computing power based on cloud servers, have emerged. An Android emulator is software that can run and simulate the Android system on personal computers, tablets, mobile phones, and other terminals. It allows users to install, use, and uninstall Android applications. Using an Android emulator, users can use mobile applications even without high-performance mobile hardware.

[0003] As Android software iterates and updates, the software in the emulator also needs to be updated and upgraded to adapt to its development. In the current technology, most emulators update system applications by starting the "Android Debug Bridge" to transfer files. This update method takes time in terms of instruction escaping and emulation, and the corresponding transfer service also occupies a certain amount of space, resulting in low software update efficiency.

[0004] When software is updated, users often cancel the upgrade and revert to the original version due to reasons such as low adaptability or incompatibility with their own habits. However, the process is lengthy and complicated, causing a lot of inconvenience to users. Summary of the Invention

[0005] This invention provides a software update method and system based on an ARM server, aiming to solve the problems of low software update efficiency caused by the fact that most emulators in the prior art update system applications by starting an "Android debug bridge" for file transfer. This update method consumes time in instruction escaping and emulation, and the corresponding transfer service also occupies a certain amount of space. In addition, users often cancel the software upgrade and revert to the original version due to low adaptability or incompatibility with their own habits after the software is updated. However, the process is lengthy and complicated, causing many inconveniences to users.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] A software update method based on an ARM server includes the following steps:

[0008] S1: Run a distributed version control system in a Linux environment. The distributed version control system includes differential files and source devices. The requesting device sends a connection verification request to access the source device.

[0009] S2: The source device parses the connection verification information and verifies whether the connection request is successful. If the connection request is successfully verified, the source device and the requesting device establish continuous communication preparation; if the connection request is not successfully verified, the source device does not establish communication preparation with the requesting device.

[0010] S3: The source device receives the update request from the requesting device and transmits the source device software information to the requesting device;

[0011] S4: The requesting device receives the source device software information, compares the source device software information with the requesting device software information, and determines whether the software needs to be updated;

[0012] S5: The requesting device provides a list of software that needs to be updated, i.e., an update list, and transmits the update list to the source device;

[0013] S6: The source device receives the updated list and parses the software type in the updated list;

[0014] S7: The source device selects the appropriate software update method according to the type of software in the update list and transmits the corresponding software update file to the requesting device;

[0015] S8: The requesting device receives the software update file. If the update process proceeds without error, the software update is completed. If an error occurs during the update process, the distributed version control system initiates a retrieval program. When the update data is successfully retrieved, the requesting device can undo the corresponding increment and complete the grayscale rollback based on the records in the differential file, thus completing the retrieval and ending the software update. When the update data retrieval fails, the retrieval program reports an error, ends the retrieval, and terminates the software update. The differential file describes the differences between different versions of the same software and records historical operations performed on the file.

[0016] Preferably, if an anomaly occurs during step S8 of the update process, the distributed version control system initiates a retrieval program, specifically as follows:

[0017] S81: Retrieve update records. If update data is successfully retrieved, the distributed version control system starts a rollback procedure and rolls back the corresponding increment to the requesting device based on the records in the differential file. If the data retrieval fails, it is handled as an exception. The distributed version control system reports an exception, and the retrieval is completed.

[0018] S82: After the rollback procedure performs an operation rollback on the application device, it performs a configuration rollback;

[0019] S83: The rollback procedure performs a software rollback of the restored configuration, i.e., the restored configuration;

[0020] S84: After the rollback program performs a software rollback, it obtains the restored configuration, that is, restores the configuration, realizes the gray-scale rollback, the rollback is completed, the rollback program exits, and the software update ends.

[0021] Preferably, in step S6, the source device receives the update list and parses the types of software in the update list. The types of software further include: unupdated software, gray-scale update software, and updated software.

[0022] For example, there are different versions A and B, where version A is higher than version B;

[0023] If the application version is B, then the application is not updated.

[0024] If the application version is A, then the application is an updated software;

[0025] If the application version is not clearly defined as A or B, and is used as B, then the application is a gray-scale update software.

[0026] Preferably, in step S7, the source device selects the appropriate software update method according to the type of software in the update list and transmits the corresponding software update file to the requesting device. The software update method further includes: active update, passive update, and idle update.

[0027] Active update: An update method in which the server proactively pushes application updates to the device;

[0028] Passive update: The method of updating when the server receives an update request from a client or when the application triggers update conditions;

[0029] Idle update: An update method in which applications with no business or no effective business are not required to perform any update actions.

[0030] A software update system based on an ARM server includes: a request device, a source device, a differential file module, a classification and recognition module, a retrieval module, and a rollback module, and is configured to perform the following steps:

[0031] S51: The requesting device sends a connection verification request to access the source device;

[0032] S52: The source device parses the connection verification information and verifies whether the connection request is successful. If the connection request is successfully verified, the source device and the requesting device establish continuous communication preparation; if the connection request is not successfully verified, the source device does not establish communication preparation with the requesting device.

[0033] S53: The source device receives the update request from the requesting device and transmits the source device software information to the requesting device;

[0034] S54: The requesting device receives the source device software information, compares the source device software information with the requesting device software information, and determines whether the software needs to be updated;

[0035] S55: The requesting device provides a list of software that needs to be updated, i.e., an update list, and transmits the update list to the source device;

[0036] S56: The source device receives the updated list, and the classification and identification module parses the type of software in the updated list;

[0037] S57: The source device selects the corresponding software update method according to the type of software in the update list parsed by the classification and identification module, and transmits the corresponding software update file to the requesting device;

[0038] S58: The application device receives the software update file. If the update process is normal, the software update is completed. If the update process is abnormal, the retrieval module starts the retrieval program. When the update data is successfully retrieved, the rollback module cancels the corresponding increment according to the record in the differential file to complete the grayscale rollback. When the update data is retrieved but fails, the retrieval module reports an error, ends the retrieval, and the software update is terminated.

[0039] Preferably, if an anomaly occurs during the update process, the retrieval module initiates a retrieval program, specifically as follows:

[0040] If the data is successfully retrieved, the rollback module will roll back the corresponding increment to the requesting device based on the records in the differential file. If the data retrieval fails, it will be handled as an exception, and the retrieval module will report an exception and the retrieval will be completed.

[0041] After the rollback module performs an operation rollback on the requested device, it performs a configuration rollback.

[0042] The rollback module performs a software rollback of the restored configuration, i.e., the restored configuration.

[0043] After the rollback module performs a software rollback, it obtains the restored configuration, i.e., restores the configuration, realizes the gray-scale rollback, the rollback is completed, the rollback program exits, and the software update ends.

[0044] Preferably, the source device receives the updated list, and then the classification and identification module parses the software type in the updated list. The classification and identification module sets the software type as unupdated software, gray-scale update software, and updated software.

[0045] Preferably, the source device selects the corresponding software update method according to the type of software in the update list parsed by the classification and identification module, and transmits the corresponding software update file to the requesting device. The software update method further includes active update, passive update, and idle update.

[0046] Compared with the prior art, the present invention has the following technical effects:

[0047] 1. The software update method and system based on an ARM server described in this invention modify and update software files by running an emulator in a Linux environment and enabling a Linux file system (i.e., a distributed version control system) outside the emulator. The source device of the distributed version control system stores file information for each version of the software. When an application is updated, the device can obtain the updated resources from the template file and directly acquire the installation-free file through system-level file copying, thereby reducing resource consumption, shortening time consumption, and improving the efficiency of software updates.

[0048] 2. The software update method and system based on an ARM server described in this invention, after the source device receives the update list, can parse the types of software in the update list. The software types include three types: unupdated software, gray-scale update software, and updated software. This precise classification of software facilitates the selection of subsequent software upgrade methods, making the update process more suitable for the software itself and further meeting user needs.

[0049] 3. The software update method and system based on an ARM server described in this invention, wherein the source device selects the corresponding software update method according to the type of software in the update list, and transmits the corresponding software update file to the requesting device. The software update method further includes active update, passive update, and idle update; the highly compatible update method enables users to access the latest version of the software in a timely manner, and the updated software improves the user experience to a certain extent.

[0050] 4. The software update method and system based on an ARM server described in this invention solves the problem that users often cancel software upgrades and revert to the original version due to low adaptability or incompatibility with their habits after an update. However, this process is lengthy and complicated, causing many inconveniences for users. By adopting the gray-scale update technology, two or more service components are deployed simultaneously for different versions, gradually switching access traffic from the old version to the new version. If any problems are encountered during the traffic transfer process, a rollback can be performed at any time to ensure that the entire system can continue to provide services.

[0051] 5. The software update method and system based on an ARM server described in this invention, wherein the application device, source device, differential file module, classification and identification module, retrieval module and rollback module of the software update system work together to improve the efficiency of software updates and meet the user's needs for gray-scale updates.

[0052] 6. The software update method and system based on an ARM server described in this invention uses a classification and identification module to accurately classify and upgrade the software, thereby enhancing the user experience.

[0053] 7. The software update method and system based on an ARM server described in this invention combines a retrieval module and a rollback module. The retrieval module searches for data, and after the data is retrieved, the rollback module performs an operation rollback on the requesting device by canceling the corresponding incremental record of the differential file. This provides users with more choices, better suits the user experience, allows for easy switching between old and new versions, and is quick and efficient. Attached Figure Description

[0054] Figure 1 This is a flowchart illustrating a software update method based on an ARM server as described in this invention.

[0055] Figure 2 This is a schematic diagram of the process in which the requesting device requests a connection to the source device for an update in a software update method based on an ARM server as described in this invention.

[0056] Figure 3 This is a schematic diagram of the gray-scale rollback process in a software update method and system based on an ARM server as described in this invention. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present application and with reference to the accompanying drawings.

[0058] A software update method based on an ARM server includes the following steps:

[0059] S1: Run a distributed version control system in a Linux environment. The distributed version control system includes differential files and source devices. The requesting device sends a connection verification request to access the source device.

[0060] The differential file is a file in a distributed version control system that describes the differences between different versions of software with the same name and records the operations performed on the file throughout history.

[0061] The source device is the device in the distributed version control system that receives update requests and verification information.

[0062] The application device stores the software currently used by the user, which can be classified and identified by the classification and recognition module as unupdated software, gray-scale update software, or updated software.

[0063] S2: The source device parses the connection verification information and verifies whether the connection request is successful. If the connection request is successfully verified, the source device and the requesting device prepare to establish continuous communication. If the connection request is not successfully verified, the source device does not prepare to establish communication with the requesting device.

[0064] S3: The source device receives the update request from the requesting device and transmits the source device software information to the requesting device.

[0065] S4: The requesting device receives the source device software information, compares the source device software information with the requesting device software information, and determines whether the software needs to be updated.

[0066] S5: The requesting device provides a list of software that needs to be updated, i.e., an update list, and transmits the update list to the source device.

[0067] S6: The source device receives the updated list and parses the software type in the updated list.

[0068] S7: The source device selects the corresponding software update method according to the type of software in the update list and transmits the corresponding software update file to the requesting device. The source device of the distributed version control system stores the file information of each version of each software. When the application is updated, the device can obtain the updated resources from the template file and directly obtain the installation-free file through the system-level file copying method to complete the installation, thereby reducing resource consumption, shortening time consumption, and improving the efficiency of software update.

[0069] S8: The requesting device receives the software update file. If the update process is normal, the software update is completed. If the update process encounters an error, the distributed version control system starts a retrieval program. When the update data is successfully retrieved, the requesting device can cancel the corresponding increment based on the record in the differential file to complete the grayscale rollback, thus completing the retrieval and ending the software update. When the update data retrieval fails, the retrieval program reports an error, ends the retrieval, and terminates the software update.

[0070] If an anomaly occurs during step S8 of the update process, the distributed control system initiates a retrieval program, specifically as follows:

[0071] If the data is successfully retrieved, the distributed control system initiates a rollback procedure, canceling the corresponding increment based on the records in the differential file to roll back the operation on the requesting device; if the data retrieval fails, it is handled as an exception, the distributed control system reports an exception, and the retrieval is completed.

[0072] After the rollback procedure rolls back the operation of the application device, it rolls back the configuration.

[0073] The rollback procedure performs a software rollback of the restored configuration, i.e., the restored configuration.

[0074] After the rollback procedure performs a software rollback, it obtains the restored configuration, i.e., restores the configuration, achieving a gradual rollback. Once the rollback is complete, the rollback procedure exits, and the software update ends. This solves the problem that often, after an update, users cancel the software upgrade and revert to the original version due to low adaptability or incompatibility with their habits. However, this process is lengthy and complicated, causing many inconveniences for users.

[0075] By employing the canary update technique, two or more service components are deployed simultaneously for different versions, gradually switching access traffic from the old version to the new version. If any problems are encountered during the traffic transfer process, a rollback can be performed at any time to ensure that the entire system can continue to provide services.

[0076] In step S6, the source device receives the update list and then parses the software types in the update list. The software types further include unupdated software, gray-scale update software, and updated software. This precise classification of the software facilitates the selection of subsequent software upgrade methods, making the update process more in line with the software's own situation and further meeting user needs.

[0077] In step S7, the source device selects the corresponding software update method according to the type of software in the update list and transmits the corresponding software update file to the requesting device. The software update method further includes active update, passive update, idle update, and high-fit update method, so that users can access the latest version of the software in a timely manner. The updated software improves the user experience to a certain extent.

[0078] A software update system based on an ARM server includes a device request module, a source device module, a differential file module, a classification and identification module, a retrieval module, and a rollback module, comprising the following steps:

[0079] S51: The requesting device sends a connection verification request to access the source device.

[0080] S52: The source device parses the connection verification information and verifies whether the connection request is successful. If the connection request is successfully verified, the source device and the requesting device prepare for continuous communication. If the connection request is not successfully verified, the source device does not prepare for communication with the requesting device.

[0081] S53: The source device receives the update request from the requesting device and transmits the source device software information to the requesting device;

[0082] S54: The requesting device receives the source device software information, compares the source device software information with the requesting device software information, and determines whether the software needs to be updated.

[0083] S55: The requesting device provides a list of software that needs to be updated, i.e., an update list, and transmits the update list to the source device.

[0084] S56: The source device receives the updated list, and the classification and identification module parses the software type in the updated list.

[0085] S57: The source device selects the corresponding software update method according to the type of software in the update list parsed by the classification and identification module, and transmits the corresponding software update file to the requesting device.

[0086] S58: The requesting device receives the software update file. If the update process proceeds without error, the software update is completed. If an error occurs during the update process, the retrieval module initiates a retrieval program. When the update data is successfully retrieved, the rollback module cancels the corresponding increment based on the records in the differential file to complete the grayscale rollback. When the update data retrieval fails, the retrieval module reports an error, ends the retrieval, and terminates the software update. The requesting device, source device, differential file module, classification and recognition module, retrieval module, and rollback module work together to improve the efficiency of the software update and meet the user's needs for grayscale updates.

[0087] When an error occurs during the update process, the retrieval module initiates a retrieval program, specifically as follows:

[0088] If the data is successfully retrieved, the rollback module will roll back the corresponding increment to the application device based on the records in the differential file. If the data retrieval fails, it will be handled as an exception, and the retrieval module will report an exception and the retrieval will be completed.

[0089] After the rollback module rolls back the operation of the application device, it performs a configuration rollback.

[0090] The rollback module performs a software rollback of the restored configuration, i.e., the restored configuration.

[0091] After the rollback module performs a software rollback, it obtains the restored configuration, i.e., restores the configuration, realizing the rollback of the grayscale. Once the rollback is complete, the rollback program exits, and the software update ends. The retrieval module and the rollback module work together. The retrieval module searches for data, and after the data is retrieved, the rollback module cancels the records of the differential file and performs the corresponding incremental operation rollback on the application device, giving users more choices, conforming to the user experience, and allowing them to switch freely between the old and new versions. The process is short and efficient.

[0092] The source device receives the updated list, and then the classification and identification module parses the software type in the updated list. The classification and identification module sets the software type as unupdated software, gray-scale update software, and updated software. The classification and identification module accurately classifies the software and accurately upgrades the software, thereby improving the user experience.

[0093] The source device selects the corresponding software update method based on the software type in the update list parsed by the classification and identification module, and transmits the corresponding software update file to the requesting device. The software update method further includes active update, passive update, and idle update.

[0094] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the inventive concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A software update method based on an ARM server, characterized in that, Includes the following steps: S1: Run a distributed version control system in a Linux environment. The distributed version control system includes differential files and source devices. The requesting device sends a connection verification request to access the source device. S2: The source device parses the connection verification information and verifies whether the connection request is successful. If the connection request is successfully verified, the source device and the requesting device establish continuous communication preparation; if the connection request is not successfully verified, the source device does not establish communication preparation with the requesting device. S3: The source device receives the update request from the requesting device and transmits the source device software information to the requesting device; S4: The requesting device receives the source device software information, compares the source device software information with the requesting device software information, and determines whether the software needs to be updated; S5: The requesting device provides a list of software that needs to be updated, i.e., an update list, and transmits the update list to the source device; S6: The source device receives the updated list and parses the software type in the updated list; S7: The source device selects the appropriate software update method according to the type of software in the update list and transmits the corresponding differential file to the requesting device; S8: The application device receives the differential file. If the update process is normal, the software update is completed. If an anomaly occurs during the update process, the distributed version control system initiates a retrieval program. If the update data retrieval is successful, the requesting device can revert the corresponding incremental rollback based on the records in the differential file, completing the retrieval and ending the software update. If the update data retrieval fails, the retrieval program reports an anomaly, terminates the retrieval, and ends the software update. The retrieval program specifically includes: S81: Retrieve update records. If update data is successfully retrieved, the distributed version control system starts the rollback procedure and rolls back the corresponding increment to the application device according to the records in the differential file. If data retrieval fails, it is handled as an exception, and the distributed version control system reports an exception, indicating that the retrieval is complete. S82: After the rollback procedure performs an operation rollback on the application device, it performs a configuration rollback; S83: The rollback procedure performs a software rollback of the restored configuration, i.e., the restored configuration; S84: After the rollback program performs a software rollback, it obtains the restored configuration, i.e., restores the configuration, realizes the gray-scale rollback, the rollback is completed, the rollback program exits, and the software update ends.

2. The software update method based on an ARM server according to claim 1, characterized in that, In step S6, the source device receives the update list and parses the software types in the update list. The software types further include: unupdated software, gray-scale update software, and updated software.

3. The software update method based on an ARM server according to claim 1, characterized in that, In step S7, the source device selects the appropriate software update method according to the type of software in the update list and transmits the corresponding differential file to the requesting device. The software update method further includes: active update, passive update, and idle update.

4. A software update system based on an ARM server, characterized in that, include: The system requests the equipment, source equipment, differential file module, classification and recognition module, retrieval module, and rollback module, and is configured to perform the following steps: S51: The requesting device sends a connection verification request to access the source device; S52: The source device parses the connection verification information and verifies whether the connection request is successful. If the connection request is successfully verified, the source device and the requesting device prepare for continuous communication. If the connection request is not successfully verified, the source device does not prepare for communication with the requesting device. S53: The source device receives the update request from the requesting device and transmits the source device software information to the requesting device; S54: The requesting device receives the source device software information, compares the source device software information with the requesting device software information, and determines whether the software needs to be updated; S55: The requesting device provides a list of software that needs to be updated, i.e., an update list, and transmits the update list to the source device; S56: The source device receives the updated list, and the classification and identification module parses the type of software in the updated list; S57: The source device selects the corresponding software update method according to the type of software in the update list parsed by the classification and identification module, and transmits the corresponding differential file to the requesting device; S58: The requesting device receives the differential file. If the update process proceeds without error, the software update is completed. If an error occurs during the update process, the retrieval module initiates a retrieval program. When the retrieval of updated data is successful, the rollback module cancels the corresponding increment based on the records in the differential file to complete the grayscale rollback. When the retrieval of updated data fails, the retrieval module reports an error, ends the retrieval, and terminates the software update. The retrieval module initiates the retrieval program as follows: If the data is successfully retrieved, the rollback module will roll back the corresponding increment to the requesting device based on the records in the differential file. If the data retrieval fails, it will be handled as an exception, and the retrieval module will report an exception and the retrieval will be completed. After the rollback module performs an operation rollback on the requested device, it performs a configuration rollback. The rollback module performs a software rollback of the restored configuration, i.e., the restored configuration. After the rollback module performs a software rollback, it obtains the restored configuration, i.e., restores the configuration, realizes the gray-scale rollback, the rollback is completed, the rollback program exits, and the software update ends.

5. A software update system based on an ARM server according to claim 4, characterized in that, After the source device receives the updated list, the classification and identification module parses the software type in the updated list, and sets the software type in the classification and identification module as unupdated software, gray-scale update software, and updated software.

6. A software update system based on an ARM server according to claim 4, characterized in that, The source device selects the appropriate software update method based on the software type in the update list parsed by the classification and identification module, and transmits the corresponding differential file to the requesting device. The software update method further includes active update, passive update, and idle update.

Images