Boot method, device and equipment of Android device and storage medium

Abstract

The application discloses a booting method and device of an Android device, an equipment and a storage medium, relates to the technical field of Android devices, and the booting method comprises the following steps: in response to the Android operating system running to a preset stage on the equipment after the equipment is booted, acquiring multiple types of preset files; checking whether the multiple types of preset files are damaged by using a multi-level and differential checking method; in the case that it is checked that the preset files are damaged, deleting the damaged preset files; restarting the equipment after all the preset files are checked, and regenerating the deleted preset files, so that the equipment successfully enters an operating system desktop. The application checks whether multiple types of preset files are damaged, the coverage of the checking is wide, meanwhile, the multiple types of preset files are checked by using a multi-level and differential checking method, so that the checking efficiency and the checking accuracy are improved, and therefore, the Android device booting dead lock phenomenon can be effectively prevented.

Description

Technical Field

[0001] This application relates to the field of Android device technology, and in particular to a method, apparatus, device and storage medium for powering on an Android device. Background Technology

[0002] During Android device operation, scenarios such as power outages, storage read / write errors, or system process crashes can easily lead to corruption of three core package management configuration files: ` / data / system / packages.xml`, `packages.list`, and `prebundled-packages.list`. In addition, similar abnormal conditions can also corrupt the ` / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml` file, which is the core XML configuration file for system runtime permission management under the Android APEX architecture. When these files malfunction, they will manifest as binary garbled characters, broken XML tags, illegal unprintable characters, empty files, or abnormal file sizes. Ultimately, the device will get stuck on the logo screen during boot and will be unable to access the system desktop.

[0003] Currently available methods for recovering from boot failures have the following limitations: 1. Limited Coverage: Most patents focus on scenarios involving corrupted underlying images or entire partition failures, with only a few addressing solutions for repairing corruption of the single package management XML file, / data / system / packages.xml. However, this method of verifying and repairing a single file still cannot completely resolve the problem. 2. Coarse verification logic: It lacks differentiated and precise verification for files of different formats and platforms, making it difficult to identify hidden faults such as abnormal fields in plain text files and errors in RK-specific file formats.

[0004] Therefore, it is necessary to develop a boot method for Android devices that can effectively prevent the boot method from freezing.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a boot method, apparatus, device and storage medium for Android devices, aiming to solve the technical problems of incomplete verification file coverage, low verification efficiency and lack of differentiation in verification logic in existing Android device boot methods, which cause the device to freeze during boot.

[0007] To achieve the above objectives, this application proposes a method for powering on an Android device, the method comprising: In response to the Android operating system on the device reaching a preset stage after the device is powered on, multiple preset files are obtained; The various preset files are checked for corruption using multi-level and differential verification methods. If a preset file is found to be corrupted, delete the corrupted preset file; After all preset files have been checked, the device is restarted to regenerate the deleted preset files, allowing the device to successfully enter the operating system desktop.

[0008] In one embodiment, the step of obtaining multiple types of preset files includes: If the Android operating system has reached the early-init stage and the package management service has not yet started, obtain the / data / system / packages.xml file and the / data / system / packages.list file; In the case that the device is a Rockchip RK platform, the / data / system / prebundled-packages.list file is also obtained; If the Android operating system is Android APEX architecture, the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is also obtained.

[0009] In one embodiment, the step of checking whether multiple types of preset files are corrupted using a multi-level and differential verification method includes: Perform a first-level verification on each type of preset file; If each type of preset file passes the first-level verification, a differentiated second-level verification is performed on each type of preset file to check whether the multiple types of preset files are corrupted.

[0010] In one embodiment, the step of performing a first-level verification on each type of preset file includes: For each type of preset file, determine whether each type of preset file is empty and whether the file size of each type of preset file is less than a preset value; If each type of preset file is empty or the file size of each type of preset file is smaller than the preset value, then each type of preset file is determined to be corrupted and fails the first-level verification.

[0011] In one embodiment, the step of performing differentiated secondary verification on each type of preset file includes: Check whether the / data / system / packages.xml file contains preset tags and whether there are garbled characters in the file. If it does not contain preset tags or there are garbled characters, the / data / system / packages.xml file is determined to be corrupted. Check whether the / data / system / packages.list file includes multiple preset fixed fields. If the fixed fields are not included, the / data / system / packages.list file is deemed corrupted. Check if the / data / system / prebundled-packages.list file conforms to the preset format. If it does not conform to the preset format, the / data / system / prebundled-packages.list file is deemed corrupted. Check whether the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml contains the preset file elements and whether there are garbled characters in the file. If the file elements are not contained or there are garbled characters, the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is considered corrupted.

[0012] In one embodiment, the step of deleting the corrupted preset file further includes: If a pre-defined file is found to be corrupted, the method of synchronizing disk cache data is used to force the deletion instructions for the corrupted file temporarily stored in memory and the file system change records to be persistently written to the device's physical storage.

[0013] Furthermore, to achieve the above objectives, this application also proposes a power-on device for an Android device, the power-on device comprising: The preset file acquisition module is used to acquire multiple preset files in response to the Android operating system on the device reaching a preset stage after the device is powered on. The preset file checking module is used to check whether the multiple types of preset files are corrupted through multi-level and differential verification methods; The preset file deletion module is used to delete the corrupted preset file when it is detected that the preset file is corrupted. The device restart and file generation module is used to restart the device after all preset files have been checked, and to regenerate the deleted preset files so that the device can successfully enter the operating system desktop.

[0014] In addition, to achieve the above objectives, this application also proposes an Android device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the boot method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the boot method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the boot method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application, after the device is powered on, when the Android system reaches a preset stage, uses multi-level and differential verification methods to check whether various types of preset files are corrupted. When a certain type of preset file is found to be corrupted, the corrupted preset file is deleted. After all types of preset files have been checked, the device is restarted, and the deleted preset files are automatically regenerated. In this way, the Android device can successfully load various preset files after restarting, enabling the Android device to successfully enter the operating system desktop after booting, preventing boot-up freezes. This embodiment checks whether various types of preset files are corrupted, which is a broader coverage compared to the prior art that only checks the packages.xml file. At the same time, the use of multi-level and differential verification methods to check various types of preset files improves the efficiency and accuracy of the check, enabling the identification of corrupted preset files and the regeneration of intact preset files, thereby effectively preventing Android device boot-up freezes. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the Android device boot method of this application. Figure 2 This is a flowchart illustrating the second embodiment of the Android device boot method of this application. Figure 3 This is a flowchart illustrating the third embodiment of the Android device boot method of this application. Figure 4 for Figure 3 A flowchart illustrating an embodiment of step S201; Figure 5 This is a flowchart illustrating the fourth embodiment of the Android device boot method of this application. Figure 6 This is a flowchart illustrating Embodiment 5 of the Android device boot method of this application; Figure 7 This is a schematic diagram of the module structure of the power-on device according to an embodiment of this application; Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the power-on method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution in this application embodiment is: In response to the Android operating system on the device reaching a preset stage after the device is powered on, multiple preset files are obtained; and the multiple preset files are checked for corruption using multi-level and differential verification methods. If a preset file is found to be corrupted, the corrupted preset file is deleted; after all preset files have been checked, the device is restarted to regenerate the deleted preset files, allowing the device to successfully enter the operating system desktop.

[0025] In this embodiment, for ease of description, the following description uses an Android device as the execution subject.

[0026] Currently available methods for recovering from boot failures have the following limitations: 1. Limited Coverage: Most patents focus on scenarios involving corrupted underlying images or entire partition failures, with only a few addressing solutions for repairing corruption of the single package management XML file, / data / system / packages.xml. However, this method of verifying and repairing a single file still cannot completely resolve the problem. 2. Coarse verification logic: It lacks differentiated and precise verification for files of different formats and platforms, making it difficult to identify hidden faults such as abnormal fields in plain text files and errors in RK-specific file formats.

[0027] This application provides a solution that, when the Android operating system reaches the early-init stage and the package management service has not yet started, obtains multiple types of preset files; then, performs a first-level verification on each type of preset file; if each type of preset file passes the first-level verification, performs a differentiated second-level verification on each type of preset file; then, if a preset file is found to be corrupted, deletes the corrupted preset file by synchronizing disk cache data; finally, after all preset files have been checked, restarts the device, regenerates the deleted preset files, and enables the device to successfully enter the operating system desktop.

[0028] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a terminal or Android device capable of performing the above functions. The following description uses an Android device as an example to illustrate this embodiment and the subsequent embodiments.

[0029] Based on this, this application provides a method for booting up an Android device, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the boot method for an Android device according to this application.

[0030] In this embodiment, the power-on method includes steps S10 to S40: Step S10: In response to the Android operating system on the device reaching a preset stage after the device is powered on, multiple preset files are obtained; These preset files include package management files and runtime permission management files.

[0031] The preset files include at least two types of native core package management files: the / data / system / packages.xml file and the / data / system / packages.list file.

[0032] This step includes the files of the two core modules, package management and runtime permission management, in the file inspection scope, which can solve the freezing problem caused by corrupted files in multiple modules.

[0033] Step S20: Check whether the multiple types of preset files are corrupted using a multi-level and differential verification method; Multi-level verification method refers to using multiple levels of verification methods for the same type of files.

[0034] Differential verification methods refer to using separate verification methods for different types of files.

[0035] Step S30: If the preset file is found to be corrupted, delete the preset file; It should be noted that the deletion operation only removes the preset files and does not modify any other system or user data. After the deletion operation is completed, the system is marked as pending a restart, waiting for the device to restart.

[0036] Understandably, this involves traversing the multiple preset file types and performing file checks and deletions.

[0037] Step S40: After all preset files have been checked, the device is restarted to regenerate the deleted preset files, so that the device can successfully enter the operating system desktop.

[0038] Understandably, the device is restarted via a restart command. When the system is marked as awaiting restart, entering the restart command will cause the device to restart automatically.

[0039] It should be noted that the automatic generation of preset files is entirely completed automatically by the system's native platform customization mechanism, without the need for external intervention.

[0040] In this step, the repair process only targets and repairs the abnormal files, without altering other system configurations, user applications, or business data. It fully preserves user-defined configurations and business modifications, completely avoiding data loss issues associated with rolling back the entire partition. Furthermore, this step designs a unified, lightweight repair process for different file types on read-write partitions, improving the reliability of the repaired files.

[0041] In this embodiment, when the device powers on and the Android system reaches a preset stage, it uses multi-level and differential verification methods to check for corruption of various types of preset files. If a type of preset file is corrupted, it is deleted. After all types of preset files have been checked, the device restarts, and the deleted files are automatically regenerated. This allows the Android system to successfully load various preset files, enabling the Android device to successfully enter the operating system desktop after booting, preventing boot-up freezes. Compared to existing technologies that only verify the packages.xml file, this embodiment expands the scope of the check by checking for corruption of various types of preset files. Furthermore, the use of multi-level and differential verification methods improves the efficiency and accuracy of the check, effectively preventing Android device boot-up freezes. In addition, this embodiment requires no manual intervention throughout the entire process, automatically performing file checks, file deletions, device restarts, and file regeneration, enabling autonomous device fault repair.

[0042] Because Android devices use various types of Android operating systems and processors, a second embodiment of this application is proposed to improve the accuracy of the inspection. Based on the first embodiment of this application, content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S10 further includes steps S101 to S103: Step S101: If the Android operating system has reached the early-init stage and the package management service has not yet started, obtain the / data / system / packages.xml file and the / data / system / packages.list file; It should be noted that the steps in this embodiment can be implemented through the detection and repair script in the init phase.

[0043] After the device is powered on and started, hardware initialization and kernel loading are completed first. Once all critical partitions such as data are mounted and ready, there will be no file read / write failures, providing a basic operating environment for subsequent file detection.

[0044] The system enters the earliest early-init stage of the init process. At this time, the package management service has not yet started, so there will be no freezing due to corrupted configuration files. At this time, the built-in detection and repair scripts are scheduled to start working.

[0045] Step S102: If the device is a Rockchip RK platform, also obtain the / data / system / prebundled-packages.list file; The file / data / system / prebundled-packages.list is a pre-built file specific to the RK platform.

[0046] Step S103: If the Android operating system is Android APEX architecture, also obtain the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml.

[0047] This operation should be performed when the Android operating system version is Android 11 or above.

[0048] It should be noted that the execution order of steps S102 and S103 can be interchanged.

[0049] In this embodiment, autonomous detection is performed on core configuration files spanning multiple directories and modules during the early stages of device boot, expanding the scope of the preset file inspection and enhancing its specificity. Furthermore, this embodiment can also be applied to inspect the Rockchip RK platform and the Android APEX architecture. In addition, this embodiment can be deployed lightweightly, implemented solely through init stage scripts, without requiring modification to the Bootloader or underlying kernel code, offering strong compatibility, low modification costs, and suitability for batch embedded device scenarios.

[0050] Since there are multiple possible methods for checking preset files, a third embodiment of this application is proposed to improve the efficiency and accuracy of preset file checking. Based on the second embodiment of this application, the content that is the same as or similar to that in Embodiment 2 described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S20 further includes steps S201 to S202: S201: Perform first-level verification on each type of preset file; Level 1 verification is equivalent to pre-verifying the preset file. Specifically, it involves performing a formal verification on the preset file.

[0051] In one feasible implementation, please refer to Figure 4 Step S201 may include steps S2011 to S2012: Step S2011: For each type of preset file, determine whether each type of preset file is empty and whether the file size of each type of preset file is less than a preset value; The preset value can be 100 bytes or 200 bytes.

[0052] Step S2012: If each type of preset file is empty or the file size of each type of preset file is less than the preset value, then it is determined that each type of preset file is corrupted and fails the first-level verification.

[0053] For example: if the preset value is set to 200 bytes, and the preset file is less than 200 bytes, then the preset file is determined to have failed the first-level verification.

[0054] It is understandable that, since the preset file format is not unique and has diversity, performing step S201 can avoid directly entering the differential secondary verification when the preset file format is unqualified, thereby improving the inspection efficiency.

[0055] S202: If each type of preset file passes the first-level verification, perform a differentiated second-level verification on each type of preset file to check whether the multiple types of preset files are damaged.

[0056] The differentiated secondary verification method employs a separate verification method for each type of preset file. This makes the check more accurate, thus avoiding the phenomenon of Android devices freezing due to the failure to detect unqualified files.

[0057] In this embodiment, by performing first-level verification and differentiated second-level verification on the preset file, the efficiency and accuracy of the verification can be improved.

[0058] To illustrate in detail how this application employs a differentiated two-level verification method to inspect various preset files, a fourth embodiment of this application is proposed. Based on the third embodiment of this application, the content in this fourth embodiment that is the same as or similar to that in the third embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 5 , Figure 5 and Figure 3 The difference is that step S202 further includes steps S2021 to S2024: Step S2021: Check whether the / data / system / packages.xml file contains preset tags and whether there are garbled characters in the file. If it does not contain preset tags or there are garbled characters, the / data / system / packages.xml file is determined to be corrupted. Specifically, it checks whether the / data / system / packages.xml file contains standard XML header and footer tags. <packages> 、< / packages> If the file does not contain standard XML header and footer tags, then the file / data / system / packages.xml is considered corrupted.

[0059] Check the / data / system / packages.xml file for unprintable binary gibberish characters. If unprintable binary gibberish characters are found, the / data / system / packages.xml file is considered corrupted.

[0060] Step S2022: Check whether the / data / system / packages.list file includes multiple preset fixed fields. If the fixed fields are not included, the / data / system / packages.list file is determined to be corrupted.

[0061] Specifically, the process involves checking whether each line of the / data / system / packages.list file includes multiple preset fixed fields and whether each fixed field conforms to a preset standard. If each line does not include the multiple preset fixed fields or the fixed fields do not conform to the preset standard, the / data / system / packages.list file is determined to be corrupted.

[0062] The program reads the file content line by line, separating fields by spaces. For example, it validates six fixed standard fields per line: package name, UID, shared UID, debug flag, data directory, and public directory. It can verify that the UID and shared UID are purely numeric. It also verifies that the data directory starts with ` / data / `. If the number of fields is incorrect, the values ​​are invalid, the path is abnormal, or garbled characters are present, the file is considered corrupted.

[0063] Step S2023: Check whether the / data / system / prebundled-packages.list file conforms to the preset format. If it does not conform to the preset format, the / data / system / prebundled-packages.list file is determined to be corrupted.

[0064] Specifically, the process involves checking whether the / data / system / prebundled-packages.list file conforms to a custom format. If it does not conform to the custom format, the / data / system / prebundled-packages.list file is deemed corrupted. This step employs a dual detection method: RK custom format verification and illegal character screening. This test is performed only on Rockchip RK platform devices. It parses each line to check for conformity to the RK-specific format (e.g., 5 fixed custom fields per line), verifying that field values ​​such as installation status and preset type are within the valid range of 0-2, and that the installation path is a valid directory for RK preset applications. Simultaneously, it scans for non-printable garbled characters. If the format is abnormal, the fields are illegal, or garbled characters are present, the file is deemed corrupted.

[0065] Step S2024: Check whether the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml contains preset file elements and whether there are garbled characters in the file. If the file elements are not contained or there are garbled characters, the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is determined to be corrupted.

[0066] Specifically, the process involves checking whether the root tag of the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is missing, whether the core attributes are abnormal, and whether the key child nodes are incomplete or contain garbled characters. If the root tag is missing, or the core attributes are abnormal, or the key child nodes are incomplete or contain garbled characters, then the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is considered corrupted.

[0067] The file checked in this step is the runtime permission configuration file in the Android APEX encrypted directory. A proprietary validity check is performed using native character matching logic. The check verifies whether the file contains standard, complete beginning, end, and root tags. <runtime-permissions> 、< / runtime-permissions> Verify that the root node contains the required version and fingerprint attributes and that they are in a valid format; also verify that the file contains complete... <package>Application package node and <permission>Permission configuration child nodes show no issues with broken tags or missing nodes; global file content scanning identifies unprintable binary gibberish characters. Missing root tags, abnormal core attributes, incomplete or gibberish-containing critical child nodes indicate file corruption.

[0068] In this embodiment, a corresponding inspection method is used for each preset file. Compared to using the same method to inspect all preset files, this differentiated inspection method can improve the accuracy of the inspection, thereby effectively determining whether the preset file is corrupted. This embodiment performs differentiated and precise verification on files of different formats and platforms, and can identify hidden faults such as abnormal fields in plain text files and errors in RK proprietary file formats.

[0069] Since corrupted preset files need to be deleted before the device restart operation, a fifth embodiment of this application is proposed to effectively delete preset files. Based on the first embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to Figure 6 , Figure 6 and Figure 1 The difference is that step S30 also includes step S3A.

[0070] Step S3A: If a preset file is found to be corrupted, the method of synchronizing disk cache data is used to force the deletion instructions for the corrupted file temporarily stored in memory and the file system change records to be persistently written to the device's physical storage.

[0071] Synchronizing disk cache data refers to the repair script calling the Linux kernel's native sync operation before executing the device reboot command: forcibly writing the corrupted file deletion commands and file system change records temporarily stored in memory to the device's physical storage (flash memory / disk) to ensure that the file deletion operation takes effect completely before reboot.

[0072] The benefits of synchronizing disk cache data are: 1. Ensure 100% effectiveness of repair operations: Prevent damage files from not being truly deleted after restarting due to data not being written to memory, thus avoiding repair failure.

[0073] 2. Ensure file system consistency: Avoid data corruption caused by abnormal restarts and prevent new file corruption problems.

[0074] 3. Improve repair reliability: Adapt to scenarios where industrial / vehicle equipment is prone to abnormal power outages, and prevent data loss or storage abnormalities during the repair process.

[0075] In this embodiment, a method of synchronizing disk cache data is used to delete corrupted preset files. This ensures the reliability of deleting corrupted preset files.

[0076] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the power-on method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0077] This application also provides a boot device for an Android device; please refer to... Figure 7 The power-on device includes: The preset file acquisition module 10 is used to acquire multiple preset files in response to the Android operating system on the device running to a preset stage after the device is powered on. The preset file checking module 20 is used to check whether the multiple types of preset files are damaged through multi-level and differential verification methods; The preset file deletion module 30 is used to delete the damaged preset file when it is detected that the preset file is damaged; The device restart and file generation module 40 is used to restart the device after all preset files have been checked, and regenerate the deleted preset files so that the device can successfully enter the operating system desktop.

[0078] The boot device provided in this application, employing the boot method described in the above embodiments, can solve the technical problem of Android devices freezing during boot. Compared with the prior art, the beneficial effects of the boot device provided in this application are the same as those of the boot method provided in the above embodiments, and other technical features in the boot device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0079] This application provides an Android device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the boot method in Embodiment 1 above.

[0080] The following is for reference. Figure 8 This document illustrates a structural diagram of an Android device suitable for implementing embodiments of this application. The Android device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The Android device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0081] like Figure 8 As shown, an Android device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in read-only memory (ROM) 1002 or programs loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the Android device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows Android devices to communicate wirelessly or wiredly with other devices to exchange data. While various Android devices with different operating systems are shown in the figures, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0082] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0083] The Android device provided in this application, employing the boot method described in the above embodiments, can solve the technical problem of device boot-up freeze. Compared with the prior art, the beneficial effects of the Android device provided in this application are the same as those of the boot method provided in the above embodiments, and other technical features of this Android device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0084] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0085] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0086] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the power-on method in the above embodiments.

[0087] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0088] The aforementioned computer-readable storage medium may be included in an Android device or may exist independently and not assembled into an Android device.

[0089] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an Android device, enable the Android device to successfully enter the operating system desktop after freezing.

[0090] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0092] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0093] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described boot method, thereby solving the technical problem of Android devices freezing during boot. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the boot method provided in the above embodiments, and will not be repeated here.

[0094] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the boot method described above.

[0095] The computer program product provided in this application can solve the technical problem of Android devices freezing during startup. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the startup method provided in the above embodiments, and will not be repeated here.

[0096] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.< / permission> < / package>

Claims

1. A method for booting up an Android device, characterized in that, The power-on method includes: In response to the Android operating system on the device reaching a preset stage after the device is powered on, multiple preset files are obtained; The multi-level and differential verification methods are used to check whether the preset files of the various types are corrupted; If a preset file is found to be corrupted, delete the corrupted preset file; After all preset files have been checked, the device is restarted to regenerate the deleted preset files, allowing the device to successfully enter the operating system desktop.

2. The power-on method as described in claim 1, characterized in that, The steps for obtaining multiple types of preset files include: If the Android operating system has reached the early-init stage and the package management service has not yet started, obtain the / data / system / packages.xml file and the / data / system / packages.list file; In the case that the device is a Rockchip RK platform, the / data / system / prebundled-packages.list file is also obtained; If the Android operating system is Android APEX architecture, the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is also obtained.

3. The power-on method as described in claim 2, characterized in that, The steps for checking whether multiple types of preset files are corrupted using multi-level and differential verification methods include: Perform a first-level verification on each type of preset file; If each type of preset file passes the first-level verification, a differentiated second-level verification is performed on each type of preset file to check whether the multiple types of preset files are corrupted.

4. The power-on method as described in claim 3, characterized in that, The steps for performing first-level verification on each type of preset file include: For each type of preset file, determine whether each type of preset file is empty and whether the file size of each type of preset file is less than a preset value; If each type of preset file is empty or the file size of each type of preset file is smaller than the preset value, then each type of preset file is determined to be corrupted and fails the first-level verification.

5. The power-on method as described in claim 3, characterized in that, The step of performing differential secondary verification on each type of preset file includes: Check whether the / data / system / packages.xml file contains preset tags and whether there are garbled characters in the file. If it does not contain preset tags or there are garbled characters, the / data / system / packages.xml file is determined to be corrupted. Check whether the / data / system / packages.list file includes multiple preset fixed fields. If the fixed fields are not included, the / data / system / packages.list file is deemed corrupted. Check if the / data / system / prebundled-packages.list file conforms to the preset format. If it does not conform to the preset format, the / data / system / prebundled-packages.list file is deemed corrupted. Check whether the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml contains the preset file elements and whether there are garbled characters in the file. If the file elements are not contained or there are garbled characters, the file / data / misc_de / 0 / apexdata / com.android.permission / runtime-permissions.xml is considered corrupted.

6. The power-on method according to any one of claims 1 to 5, characterized in that, The step of deleting the corrupted preset file further includes: If a pre-defined file is found to be corrupted, the method of synchronizing disk cache data is used to force the deletion instructions for the corrupted file temporarily stored in memory and the file system change records to be persistently written to the device's physical storage.

7. A power-on device for an Android device, characterized in that, The power-on device includes: The preset file acquisition module is used to acquire multiple preset files in response to the Android operating system on the device reaching a preset stage after the device is powered on. The preset file checking module is used to check whether the multiple types of preset files are corrupted through multi-level and differential verification methods; The preset file deletion module is used to delete the corrupted preset file when it is detected that the preset file is corrupted. The device restart and file generation module is used to restart the device after all preset files have been checked, and to regenerate the deleted preset files so that the device can successfully enter the operating system desktop.

8. An Android device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the power-on method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the boot method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the boot method as described in any one of claims 1 to 6.

Images