Display equipment, boot animation setting method and device and storage medium
By adding a target interface and priority path mechanism to the display device, users can easily and securely replace the boot animation, solving the problems of complex operation and security risks in the existing technology, and improving user experience and system compatibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-03-27
AI Technical Summary
In existing technologies, setting user-customized boot animations requires professional knowledge and complex operations, resulting in a poor user experience and security risks.
By adding a target interface to the display device and combining it with the priority characteristics of the system boot animation loading path, users can easily write the target boot animation to the highest priority path by simply operating on the interface of the target application, thus achieving safe and convenient replacement of the boot animation.
Without requiring root access or flashing capabilities, users can personalize the boot animation, enhancing the user experience and improving system security and compatibility.
Smart Images
Figure CN121742950A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of display device technology, and in particular to a display device, a method for setting a boot animation, an apparatus, and a storage medium. Background Technology
[0002] Boot animation is the first visual interface a user encounters when starting up a display device, and it is an important part of device personalization. User demand for personalization is growing, especially among younger users who want to express the uniqueness of their devices through customized boot animations (such as changing brand animations, adding fun elements, and adapting to theme styles).
[0003] In existing technologies, the system image of the display device is recompiled and flashed onto the display device, and a custom boot animation is embedded into the system partition to set the boot animation of the display device.
[0004] However, the above methods require users to have system-level development capabilities and to customize images for different device models, which is a cumbersome process and results in a poor user experience. Summary of the Invention
[0005] This application provides a display device, a method, apparatus, and storage medium for setting boot animations, which allows users to set boot animations without performing complex operations, effectively improving the user experience.
[0006] In a first aspect, embodiments of this application provide a display device, the display device comprising:
[0007] A display screen used for displaying images;
[0008] The processor connected to the display screen is configured to:
[0009] The target application's interface is displayed on the screen; the target application is used to set the boot animation.
[0010] In response to a target operation for setting a boot animation, a target boot animation is written to a target path via a pre-created target interface so that the display device plays the target boot animation when it is powered on.
[0011] The target operation is input on the interface of the target application, and the target path is the highest priority writable path among the paths for loading the boot animation when the display device is powered on.
[0012] In one possible implementation, writing the target boot animation to the target path via a pre-created target interface includes:
[0013] The target interface is used to obtain the format information of the target boot animation and the application information of the target application.
[0014] The target application's permissions are verified based on its application information.
[0015] If the target application passes the permission verification, then the format information of the target boot animation is validated.
[0016] If the target boot animation passes the format validation, then the target boot animation is written to the target path.
[0017] In one possible implementation, the application information of the target application includes an application signature;
[0018] The permission verification of the target application based on the application information of the target application includes:
[0019] The verification process includes checking whether the application signature matches the pre-stored system signature, and / or checking whether the application signature matches the user-authorized signature.
[0020] If the application signature matches the pre-stored system signature, and / or the application signature matches the user's pre-authorized signature, then the target application is determined to have passed the permission verification.
[0021] In one possible implementation, the format verification of the target boot animation format information includes:
[0022] Verify whether the format information of the target boot animation meets the preset format requirements;
[0023] If the format information of the target boot animation meets the preset format requirements, then the target boot animation is determined to have passed the format verification.
[0024] In one possible implementation, writing the target boot animation to the target path via a pre-created target interface includes:
[0025] If there is a boot animation under the target path, then the target boot animation will be used to overwrite the original boot animation;
[0026] If there is no boot animation in the target path, then the target boot animation will be written into the target path.
[0027] In one possible implementation, the step of writing the target boot animation to the target path via a pre-created target interface in response to a target operation for setting a boot animation includes:
[0028] In response to the user's input to select a new boot animation, a boot animation selection interface is displayed, wherein the boot animation selection includes at least one boot animation;
[0029] In response to the user's selection of the target boot animation in the boot animation selection interface, the target boot animation is written to the target path through the pre-created target interface.
[0030] In one possible implementation, the step of responding to a user's selection of a target boot animation in the boot animation selection interface, and writing the target boot animation to a target path through a pre-created target interface, includes:
[0031] In response to the user's selection of a target boot animation in the boot animation selection interface, a boot animation preview interface is displayed; the boot animation preview interface includes a preview animation control and a confirmation control;
[0032] In response to the user's operation on the preview animation control, the target boot animation is played on the display screen;
[0033] In response to the user's operation on the confirmation control, the target boot animation is written to the target path through a pre-created target interface.
[0034] In one possible implementation, after writing the target boot animation to the target path via a pre-created target interface, the process includes:
[0035] Output a prompt message to inform the user that the boot animation has been successfully set.
[0036] In one possible implementation, the processor is further configured to:
[0037] In response to a formatting operation input by the user, the boot animation written to the target path is deleted so that the display device plays the default boot animation the next time it is powered on.
[0038] In one possible implementation, the display device is equipped with an Android system, and the target interface is a write file interface pre-created in the Framework layer of the Android system.
[0039] Secondly, embodiments of this application provide a boot animation setting method, applied to a display device as described in the first aspect and / or various possible embodiments of the first aspect, the method comprising:
[0040] A display screen used for displaying images;
[0041] The processor connected to the display screen is configured to:
[0042] The target application's interface is displayed on the screen; the target application is used to set the boot animation.
[0043] In response to a target operation for setting a boot animation, a target boot animation is written to a target path via a pre-created target interface so that the display device plays the target boot animation when it is powered on.
[0044] The target operation is input on the interface of the target application, and the target path is the highest priority writable path among the paths for loading the boot animation when the display device is powered on.
[0045] Thirdly, embodiments of this application provide a boot animation setting device, including:
[0046] The display module is used to display the interface of a target application through the display screen of a display device, wherein the target application is an application used for setting boot animation;
[0047] A processing module is configured to respond to a target operation for setting a boot animation by writing a target boot animation to a target path through a pre-created target interface, so that the display device plays the target boot animation when it boots up; wherein the target operation is input on the interface of the target application, and the target path is the highest priority writable path among the boot animation loading paths when the display device boots up.
[0048] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the first aspect and / or various possible implementations of the first aspect.
[0049] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in the first aspect and / or various possible implementations of the first aspect.
[0050] The display device, boot animation setting method, apparatus, and storage medium provided in this application embodiment include: a display screen for displaying images; and a processor connected to the display screen, configured to: display the interface of a target application on the display screen, the target application being an application for setting a boot animation; and, in response to a target operation for setting a boot animation, write the target boot animation to a target path through a pre-created target interface, so that the display device plays the target boot animation upon startup; wherein the target operation is input on the interface of the target application, and the target path is the highest priority writable path among the boot animation loading paths when the display device starts up. In this way, by pre-creating a target interface capable of writing boot animations, users can easily have the processor write a new boot animation to the highest priority writable path through the target interface. Since the written path has the highest loading priority, when the device starts up subsequently, the boot animation is loaded first under this path, thus loading and playing the written boot animation, thereby replacing the boot animation. This eliminates the need for complex user operations and effectively improves the user experience. Attached Figure Description
[0051] 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.
[0052] Figure 1 A schematic diagram of the structure of a display device provided in this application;
[0053] Figure 2 A flowchart illustrating a boot animation setting method provided in this application;
[0054] Figure 3 A schematic diagram of an interface for selecting a boot animation provided in this application;
[0055] Figure 4 A schematic diagram of the interface interaction for confirming the boot animation provided in this application;
[0056] Figure 5 This application provides a flowchart illustrating a method for writing a boot animation.
[0057] Figure 6 This application provides a flowchart illustrating a method for setting a boot animation in an Android system.
[0058] Figure 7 A schematic diagram illustrating the restart process of a display device provided in this application;
[0059] Figure 8 A schematic diagram illustrating a method for restoring the default boot animation provided in this application;
[0060] Figure 9 This is a schematic diagram of a startup animation setting device provided in this application.
[0061] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0062] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0063] The boot animation of a display device is the first visual interface a user encounters when starting the device, directly impacting their first impression and personalized experience. Boot animations not only convey brand identity and device functionality but also project device performance and system smoothness through dynamic visual effects. Currently, user demand for personalization is growing, especially among younger users who want to express their device's uniqueness through customized boot animations (such as changing brand animations, adding fun elements, or adapting to different themes).
[0064] In some implementations, users need to obtain root access to the device, change the system partition (such as / system) from read-only mode to read-write mode, manually replace the boot animation file, and then restore the partition permissions.
[0065] However, while this method can replace the boot animation, it is complex and requires specialized knowledge, making it difficult for ordinary users to perform. Furthermore, rooting compromises system security mechanisms, potentially leading to malware tampering with system files, causing device malfunctions or privacy breaches.
[0066] In other implementations, a custom boot animation is embedded in the system partition by recompiling the system image and flashing it onto the device.
[0067] However, this method requires developers to have system-level development capabilities and necessitates customizing images for different device models, resulting in poor universality. Flashing the device carries a high risk, as errors can render the device unusable, and restoring factory settings requires re-flashing, a cumbersome process.
[0068] Based on this, the display device and boot animation setting method provided in this application, by adding a target interface capable of writing boot animations and combining the priority characteristics of the system boot animation loading path, writes the target boot animation to the highest priority target path through the target interface based on the user's input for setting the boot animation in the target application's interface. This ensures that when the display device boots up subsequently, when loading files under the target path first, the written target boot animation can be loaded and played. This achieves secure and convenient boot animation replacement without root access, allowing users to set boot animations with simple operations and improving the user experience.
[0069] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0070] The display device provided in this application is suitable for personalized needs scenarios of a large user group.
[0071] For example, this application applies to all display devices based on the Android operating system. Users can use a built-in or third-party authorized personalization settings application (i.e., the target application) to call the file writing interface provided by the Framework layer (i.e., the target interface) to write a custom boot animation file to the system temporary storage path Path1 (i.e., the target path). When the device boots up next time, the system will prioritize loading the animation file in Path1 to display the personalized boot animation.
[0072] This solution does not require users to have root access or the ability to flash ROMs, and it is compatible with different brands and versions of Android devices.
[0073] Figure 1 A schematic diagram of a display device provided in this application. Please refer to [link / reference]. Figure 1 The display device 10 may include a processor 11 and a display screen 12.
[0074] Display device 10 can be a device with a display screen. For example, display device 10 can be a smartphone, tablet, wearable device, etc.
[0075] Processor 11 can be a central processing unit (CPU) or a graphics processing unit (GPU).
[0076] The display screen 12 can display images. The display screen 12 can be connected to the processor 11.
[0077] In this application, the display screen 12 can be used to display various interfaces during the boot animation setup process, and can also be used to display the boot animation when the display device is powered on.
[0078] The boot animation setting method provided in this application is applied to the display device described in the above embodiments. Figure 2 This is a flowchart illustrating a method for setting a boot animation as provided in this application.
[0079] like Figure 2 As shown, the method for setting up the boot animation includes the following steps:
[0080] S201. Display the interface of the target application on the screen. The target application is the application used to set the boot animation.
[0081] The target application can be a system settings application or a licensed third-party application used for setting boot animations. For example, it can be a personalized settings application for the display system or a third-party licensed customized application. This application embodiment does not limit the target application.
[0082] For example, the processor may display the interface of the target application on a display screen in response to an operation to open the target application.
[0083] S202, In response to the target operation for setting the boot animation, the target boot animation is written to the target path through a pre-created target interface so that the display device plays the target boot animation when it is powered on.
[0084] The target operation is entered on the target application's interface, and the target path is the highest priority writable path among the paths for loading the boot animation when the display device boots up.
[0085] The target application is bound to the target interface. The target boot animation is written to the target path through the pre-created target interface. You can call the target interface first, and then write the target boot animation to the target path through the target interface.
[0086] For example, the target boot animation may include images, audio, and other content. For instance, the target boot animation may include a desc.txt file, an animation frame image folder, and audio files.
[0087] For example, the target path can be the result of technical personnel analyzing the boot animation loading process of the display device system during the development phase, determining multiple reading paths for loading the boot animation when the system starts, and filtering out the target path with the highest priority.
[0088] Alternatively, a path priority mapping table corresponding to different device models and system versions can be preset, and the priority of the system loading path can be dynamically adjusted according to the identification results (such as prioritizing reading / vendor / etc / bootanimation.zip on some devices).
[0089] For example, / data / local / bootanimation.zip is the common Path1, / system / media / bootanimation.zip is the common Path2, and user-defined path configuration is also supported.
[0090] In this way, by dynamically adapting partition paths and permission configurations for different devices, the compatibility issues that require device-specific adaptation in existing technologies are resolved, improving the versatility of the solution. At the same time, the dynamic path mapping table allows users to customize paths, further meeting the personalized needs of special devices and enhancing the flexibility of the solution.
[0091] In this application, in response to a target operation for setting a boot animation, writing a target boot animation to a target path through a pre-created target interface may include: in response to a user input operation to select a new boot animation, displaying a boot animation selection interface, wherein the boot animation selection includes at least one boot animation; and in response to a user's selection operation for a target boot animation in the boot animation selection interface, writing the target boot animation to the target path through the pre-created target interface.
[0092] Figure 3 This is a schematic diagram of an interface for selecting a boot animation, provided in this application.
[0093] like Figure 3 As shown in (a), the target application's interface may include the current boot animation, a custom boot animation control for determining the boot animation settings, and an operation on the custom boot animation control by the user to select a new boot animation. The processor responds to this user operation by displaying... Figure 3 The boot animation selection interface is shown in (b) of the image.
[0094] like Figure 3 As shown in (b) of the diagram, the boot animation selection interface includes boot animation 1, boot animation 2, boot animation 3, and boot animation 4. Users can select the desired boot animation in the boot animation selection interface.
[0095] like Figure 3 As shown in (b), the user can perform a click operation on the boot animation 3 that they want to select. In response to the click operation, the processor writes the target boot animation to the target path through the pre-created target interface.
[0096] For example, the boot animation selection interface may include a boot animation that is stored locally or stored on a mobile device (such as a portable hard drive). This application embodiment does not limit this.
[0097] It should be understood that multiple storage paths can be displayed before the boot animation selection interface is shown on the screen. Users can select the corresponding storage path to display the boot animation included in that storage path on the screen.
[0098] This allows users to choose from multiple boot animations, giving them the freedom to select their preferred one and improving the user experience.
[0099] Furthermore, in response to the user's selection of the target boot animation in the boot animation selection interface, a boot animation preview interface is displayed; the boot animation preview interface includes a preview animation control and a confirmation control. In response to the user's operation on the preview animation control, the target boot animation is played on the display screen. In response to the user's operation on the confirmation control, the target boot animation is written to the target path through a pre-created target interface.
[0100] Figure 4 This application provides a schematic diagram of the interface interaction for confirming the boot animation.
[0101] When a user wants to preview the boot animation, they can click the preview animation control. The processor responds to this click and plays the target boot animation on the display device. If the user is satisfied with the selected target boot animation, they can click the confirm control. The processor responds to this click and writes the target boot animation to the target path through a pre-created target interface.
[0102] For example, the target boot animation file in the target path can be simulated and loaded in a sandbox environment, allowing the user to preview the animation effect before replacement.
[0103] Specifically, a sandbox environment is built: a lightweight animation player is embedded in the user application to simulate the animation loading process when the system starts up (such as reading the target path file, parsing desc.txt, and playing the frame sequence).
[0104] Furthermore, the preview animation is temporarily stored in the application's private directory (e.g., / data / data / com.example.app / cache / ) to avoid consuming system storage space. During the preview process, the validity of the animation file is checked in real time (e.g., abnormal frame rate, unsupported audio format), and the user is prompted to make adjustments.
[0105] For example, a user behavior analysis module can be added to the system to record the frequency of user animation replacements, common animation types, and restoration operation records, and recommend personalized animations based on the analysis results.
[0106] This behavior analysis module may include a behavior log module, a recommendation algorithm module, and a privacy protection mechanism.
[0107] The behavior log module is used to record data such as user animation replacement time, animation file source (e.g., local / network), and recovery operation trigger time at the Framework layer.
[0108] The recommendation algorithm module is used to analyze user behavior patterns based on machine learning (such as collaborative filtering algorithms) and generate an animation recommendation list (such as recommending frequently used animations or animations that match the device brand).
[0109] Privacy protection mechanisms are used to store user data locally instead of uploading it to the cloud, thereby improving data security.
[0110] This preview function reduces user operational risks and avoids system startup anomalies caused by incompatible animation files. Sandbox loading simulation ensures that the preview process does not affect system stability, while real-time feedback helps users optimize animation files and improve the success rate of operations.
[0111] In this way, by displaying a boot animation preview interface, users can preview the playback effect of the boot animation in advance, so that they can decide whether to replace the selected boot animation with the selected boot animation.
[0112] After the target boot animation is written to the target path through the pre-created target interface, the processor can output a prompt message to inform the user that the boot animation has been set successfully.
[0113] For example, the prompt message can be displayed on the interface. For instance, the interface could display the text message "Boot animation settings successful, will take effect on the next boot".
[0114] Alternatively, you can output a prompt message by playing a voice message. For example, you could play a voice message saying, "Boot animation settings successful, will take effect on the next boot."
[0115] This application does not specifically limit the method of outputting prompt information in the embodiments.
[0116] In this way, by outputting a prompt message to the user to indicate whether the boot animation setting was successful, the user can know in a timely manner whether the boot animation has been set successfully.
[0117] Therefore, the boot animation setting method provided in this application, by adding a target interface capable of writing boot animations and combining the priority characteristics of the system boot animation loading path, writes the target boot animation to the highest priority target path through the target interface based on the user's input for setting the boot animation in the target application's interface. This ensures that when the display device boots up, files under the target path are loaded first, and the written target boot animation can be loaded and played. This achieves secure and convenient boot animation replacement without root access, allowing users to set boot animations with simple operations and improving the user experience.
[0118] Figure 5 This is a flowchart illustrating a method for writing a boot animation provided in this application.
[0119] like Figure 5 As shown, the method includes:
[0120] S501. Obtain the format information of the target boot animation and the application information of the target application through the target interface.
[0121] S502. Verify the permissions of the target application based on its application information.
[0122] The target application's application information includes the application signature.
[0123] In some possible embodiments, verifying the application information of the target application to perform permission verification on the target application may include: verifying whether the application signature is consistent with the pre-stored system signature, and / or verifying whether the application signature is consistent with the authorization signature pre-authorized by the user; if the application signature is consistent with the pre-stored system signature, and / or the application signature is consistent with the authorization signature pre-authorized by the user, then it is determined that the target application has passed the curve verification.
[0124] For example, a match check between the system signature "android" and the application signature "com.example.app".
[0125] The pre-authorized signature can be one that the user manually authorized, and it is stored in the user's authorization list.
[0126] For example, users can manually grant permissions to com.example.app through app settings.
[0127] For example, when calling the target interface, the application signature is first checked to see if it matches the pre-stored system signature (such as Android). If it fails, it is further checked whether the application is in the user's authorization list (such as when the user manually authorizes com.example.app).
[0128] If the application signature does not match the pre-stored system signature, and / or the application signature does not match the user's pre-authorized signature, then the target application is determined to have failed permission verification.
[0129] For example, if the target application fails permission verification, the result of the permission failure can be displayed on the target application's interface.
[0130] By verifying the permissions of the target application, only legitimate applications can perform the animation replacement operation, which can prevent malicious software from tampering with system files by calling interfaces through unauthorized applications, thereby improving the overall security and controllability of the system.
[0131] S503. If the target application passes the permission verification, then the format information of the target boot animation is validated.
[0132] In some possible embodiments, format verification of the target boot animation may include: verifying whether the format information of the target boot animation meets preset format requirements; if the format information of the target boot animation meets the preset format requirements, then determining that the target boot animation passes the format verification.
[0133] The preset format requirements are the format requirements for the boot animation of the display device's system operation, such as the .zip compressed package structure, the validity of the desc.txt parameter, etc., but this application embodiment does not limit this.
[0134] For example, the target interface checks whether the file is in .zip format, whether it contains a desc.txt configuration file and an animation frame image folder, and verifies whether the resolution, frame rate and other parameters in desc.txt are compatible with the system.
[0135] If the format information of the target boot animation does not meet the preset format requirements, then the target boot animation is determined to have failed the format verification.
[0136] For example, if the target boot animation fails format validation, the result of failing format validation can be displayed on the target application's interface.
[0137] The result can include specific content that failed validation. For example, if the resolution validation in desc.txt fails, the validation result for the resolution in desc.txt will be output.
[0138] In some possible implementations, multilingual support and resolution adaptation functions can be added during the formatting process of animation files to ensure that the text content (such as brand logos and animation descriptions) in custom animation files is adapted to different language environments and dynamically adapted to the device screen resolution.
[0139] Specifically, multi-language resources are pre-defined in the animation file (e.g., the desc.txt file supports language tags such as en-US and zh-CN), and the animation description in the corresponding language is dynamically loaded based on the system language settings. When validating the format information of the target boot animation, the resolution of the animation frame image is checked to ensure it matches the device screen resolution. If they do not match, the image is automatically scaled or the user is prompted to adjust it.
[0140] This multilingual support enhances the international user experience and avoids animation description errors caused by language incompatibility. Resolution adaptation logic ensures consistent animation display across different devices, reducing display anomalies due to resolution differences and enhancing the solution's versatility.
[0141] In this way, by validating the format of the boot animation, invalid boot animation files can be predicted and blocked. By verifying the validity of the file format, invalid files are prevented from being written to the system, thus preventing system startup anomalies or lag caused by file errors and improving the stability and reliability of system operation.
[0142] S504. If the target boot animation passes the format validation, then write the target boot animation to the target path.
[0143] For example, if there is a boot animation in the target path, the original boot animation will be overwritten with the target boot animation.
[0144] If there is no boot animation in the target path, then write the target boot animation to the target path.
[0145] This ensures that only the newly written boot animation is stored in the target path, so that when the display device is powered on subsequently, the newly written boot animation can be loaded into the target path and played, thereby replacing the boot animation.
[0146] In some possible embodiments, an incremental update function is added to the target interface to support only transmitting and writing the differences between the custom animation file and the default animation file (such as generating patch files through a differential algorithm).
[0147] Specifically, before writing the file, a differential patch is generated by comparing the user-provided custom animation file with the default animation file stored in the target path (e.g., using the bsdiff algorithm). Only the patch file is written to the target path, not the complete animation file, reducing storage usage and data transfer. When the system loads the animation, a hash check (e.g., SHA-256) ensures that the combination of the patch file and the default file is complete and valid.
[0148] This incremental update approach reduces file transfer and storage overhead, making it particularly suitable for devices with poor network environments or limited storage space. Simultaneously, differential verification ensures the integrity of animation files, preventing system anomalies due to file corruption and further enhancing system stability.
[0149] In this embodiment, the permissions of the target application and the format of the target boot animation are verified. The boot animation is only written if the verification passes. This ensures that the boot animation can only be replaced by the target application with the required permissions. Furthermore, the format of the replaced boot animation must meet the requirements. This reduces the possibility of system attacks due to boot animation replacement and improves the stability and reliability of system operation.
[0150] The following section uses Android as the operating system installed on the display device and the file writing interface pre-created in the Android system's Framework layer as an example to explain in detail how to set up a boot animation.
[0151] Boot animation loading path identification: Analyze the boot animation loading process of the target Android system, determine multiple reading paths for loading the boot animation when the system starts, and filter out the first path with the highest priority (denoted as Path1) and the second path for storing the default boot animation file (denoted as Path2).
[0152] When the system starts up, it first reads the boot animation file in Path1. If there is no valid boot animation file in Path1, it automatically reads the default boot animation file in Path2. Path1 is a temporary storage path with read permissions only in the original system configuration, and its storage partition supports file write operations.
[0153] For example, Path1 is preferably / data / local / bootanimation.zip, which is a common temporary storage path for the Android system. The / data partition where it resides supports file write operations, and this path is accessed first by default during the system boot animation loading process. Path2 is the system's default boot animation storage path, which is usually / system / media / bootanimation.zip.
[0154] Framework layer file writing interface development: Add a permission-controlled file writing interface to the Framework layer of the Android system, which is the target interface in this application.
[0155] The file writing interface is implemented by adding a BootAnimationManager service to the SystemServer in the Android Framework layer. This service is registered as a core system service and provides an AIDL interface for user applications to call.
[0156] This interface is used to write the boot animation file to the specified Path1. Its core functions include permission verification, file format validation, file writing, and result feedback. Details are as follows:
[0157] Permission verification module: The system predefines custom permissions (such as android.permission.WRITE_BOOT_ANIMATION) and configures them as system-level permissions, allowing only legitimate applications that have been authenticated by the system or authorized by the user to access them. When an API call is made, the system first verifies whether the calling application holds the custom permission. If the verification fails, the write operation is refused, and an error message indicating insufficient permissions is returned.
[0158] For example, the permission verification of the interface is completed through the system PackageManagerService to ensure that only legitimate applications can call it.
[0159] The specific content executed by the permission verification module can be found in the relevant description of permission verification for the target application in the above embodiments, and will not be repeated here.
[0160] The file format verification module verifies whether the incoming boot animation file conforms to the format requirements of the Android system boot animation, including the file type (must be a .zip compressed file), the file structure within the compressed file (must contain a desc.txt configuration file, an animation frame image folder, and audio files (if any)), and the validity of the parameters in the desc.txt file (such as resolution, frame rate, playback duration, etc., which are compatible with the system). If the file format is invalid, a format error message is returned, and writing is refused.
[0161] For example, the file format verification module also includes file size verification. If the size of the incoming boot animation file exceeds the system's preset threshold (such as 50MB), the file will be rejected from being written to avoid excessively large files occupying system storage or causing boot lag.
[0162] The specific content executed by the permission verification module can be found in the description of format verification of the target boot animation in the above embodiments, and will not be repeated here.
[0163] File writing module: Through the file operation API (interface) of the Framework layer, the validated and legal boot animation file is written to Path1, overwriting the old animation file that already exists in Path1 (if it exists), and the file writing permissions are set to system read and interface write to ensure that the system can read it normally when it starts up.
[0164] Results feedback module: After the file is written, the module returns the operation result to the calling application, including status information such as successful writing, insufficient permissions, incorrect file format, and failed path access, so that the application can display the operation result to the user.
[0165] Based on the above description, the target application's API call to replace the animation can include: the system-certified target application (such as the system's built-in personalization settings application or a third-party authorized customized application) binds to a system service in the Framework layer or calls the AIDL interface, passing the user-selected new boot animation file (local storage or network download) as a parameter to the developed file writing interface. After the interface completes permission verification and file format verification in sequence, it writes the new boot animation file to Path1; if the writing is successful, the user application prompts the user "Boot animation setting successful, will take effect on the next boot".
[0166] Based on the description of the above embodiments, the process for setting a boot animation in the Android system can be found in [reference needed]. Figure 6 As shown, Figure 6 This application provides a flowchart illustrating a method for setting a boot animation in an Android system.
[0167] like Figure 6 As shown, the process of setting up the boot animation includes:
[0168] The user selects a new animation file through the authentication application. This application calls the file writing interface in the Framework layer, verifies the interface permissions, and determines whether the authentication application passes the permission check. If it fails, an insufficient permission result is returned. If it passes, file format verification is performed, and its validity is determined. If the format verification fails, a format error message is returned. If the format verification passes, the new boot animation is written to path 1 (Path1) via the file writing interface.
[0169] Furthermore, if the format validation passes, the system determines whether the write operation was successful. If the write operation fails, a write failure message is returned. If the write operation is successful, the user is prompted with the message "Setting successful, will take effect upon next boot".
[0170] In this application, after the user sets a target boot animation, the target boot animation can be played the next time the display device is powered on.
[0171] The process of the display device playing the target boot animation is as follows: Based on the boot command, the display device loads the target boot animation file in the target path with the highest priority according to the priority of each path through the boot animation loading service, and plays the target boot animation on the display screen; until the animation is completed, the system enters the desktop interface.
[0172] Taking the Android system as an example, the process of displaying the target boot animation when the device boots up is as follows: Figure 7 As shown, Figure 7 This application provides a schematic diagram of a display device restart process.
[0173] like Figure 7 As shown, the process of playing the target boot animation when the display device is powered on is as follows: When the user restarts the display device, the BootAnimation service reads the paths according to the preset path priority during system startup. First, it accesses path 1 (Path1) to determine if a valid file exists in path 1. If it exists, it loads and plays the new boot animation stored therein until the animation finishes playing and the system enters the desktop interface. If it does not exist, it reads the default boot animation stored in path 2 (Path2).
[0174] In this application, the display device also supports restoring the default boot animation. Specifically, the processor can respond to a user-input formatting operation by deleting the written boot animation in the target path, so that the display device plays the default boot animation the next time it is powered on.
[0175] For example, the formatting operation input by the user can be an operation to restore factory settings by selecting the settings application, or an operation to format the storage partition where the target path is located. This application embodiment does not limit this.
[0176] In this way, by automatically deleting user-defined boot animation files in the target path during system formatting, rapid restoration of the boot animation is achieved. A system-level callback mechanism ensures that the restoration process is consistent with standard operating procedures, eliminating the need for users to manually perform complex operations (such as reflashing the device or modifying system files), further improving restoration efficiency and user experience reliability.
[0177] Taking the Android system as an example, and in conjunction with the relevant descriptions of the Android system in the above embodiments, restoring the default boot animation may include: when the user performs a system formatting operation (including restoring factory settings and formatting the storage partition where Path1 is located), the system starts a partition cleanup process, automatically deleting all files in Path1 (including user-defined custom boot animation files); after the cleanup is completed, when the system starts up next time, since there are no valid files in Path1, it will automatically read and load the default boot animation file in Path2, thereby achieving a quick restoration of the default boot animation.
[0178] For example, the Path1 cleanup logic triggered by the system formatting operation can be implemented by adding a cleanup callback in PackageManagerService or MountService. When the system performs a factory reset or partition formatting, the callback is automatically called to delete the files in Path1 without requiring any additional user intervention.
[0179] Figure 8 This is a schematic diagram illustrating a method for restoring the default boot animation provided in this application.
[0180] like Figure 8 As shown, when the user triggers a recovery operation, the processor performs system formatting, and the system triggers a partition cleanup callback, automatically deleting all files in path 1. When the user restarts the device, the BootAnimation service reads the paths during system startup, prioritizing files in path 1. It checks if a valid file exists in path 1; if it does, it loads the boot animation file from path 1; otherwise, it reads the default boot animation file from path 2.
[0181] Figure 9 This is a schematic diagram of the structure of a boot animation setting device provided in this application, as shown below. Figure 9 As shown, the boot animation setting device 90 provided in this embodiment includes:
[0182] Display module 901 is used to display the interface of the target application through the display screen of the display device. The target application is an application used to set the boot animation.
[0183] The processing module 902 is used to respond to the target operation for setting the boot animation, and write the target boot animation to the target path through a pre-created target interface so that the display device plays the target boot animation when it boots up; wherein, the target operation is input on the interface of the target application, and the target path is the highest priority writable path among the paths for loading boot animation when the display device boots up.
[0184] The boot animation setting device provided in this embodiment can execute the display method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0185] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0186] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.
[0187] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0188] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0189] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.
[0190] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0191] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.
[0192] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0193] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0194] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0195] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0196] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0197] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A display device, characterized in that, The display device includes: A display screen used for displaying images; The processor connected to the display screen is configured to: The target application's interface is displayed on the screen; the target application is used to set the boot animation. In response to a target operation for setting a boot animation, a target boot animation is written to a target path via a pre-created target interface so that the display device plays the target boot animation when it is powered on. The target operation is input on the interface of the target application, and the target path is the highest priority writable path among the paths for loading the boot animation when the display device is powered on.
2. The display device according to claim 1, characterized in that, The step of writing the target boot animation to the target path through a pre-created target interface includes: The target interface is used to obtain the format information of the target boot animation and the application information of the target application. The target application's permissions are verified based on its application information. If the target application passes the permission verification, then the format information of the target boot animation is validated. If the target boot animation passes the format validation, then the target boot animation is written to the target path.
3. The display device according to claim 2, characterized in that, The application information of the target application includes the application signature; The permission verification of the target application based on the application information of the target application includes: The verification process includes checking whether the application signature matches the pre-stored system signature, and / or checking whether the application signature matches the user-authorized signature. If the application signature matches the pre-stored system signature, and / or the application signature matches the user's pre-authorized signature, then the target application is determined to have passed the permission verification.
4. The display device according to claim 2, characterized in that, The format validation of the target boot animation includes: Verify whether the format information of the target boot animation meets the preset format requirements; If the format information of the target boot animation meets the preset format requirements, then the target boot animation is determined to have passed the format verification.
5. The display device according to any one of claims 1-4, characterized in that, The step of writing the target boot animation to the target path through a pre-created target interface includes: If there is a boot animation under the target path, then the target boot animation will be used to overwrite the original boot animation; If there is no boot animation in the target path, then the target boot animation will be written into the target path.
6. The display device according to any one of claims 1-4, characterized in that, The step of responding to the target operation for setting the boot animation by writing the target boot animation to the target path through a pre-created target interface includes: In response to the user's input to select a new boot animation, a boot animation selection interface is displayed, wherein the boot animation selection includes at least one boot animation; In response to the user's selection of the target boot animation in the boot animation selection interface, the target boot animation is written to the target path through the pre-created target interface.
7. The display device according to claim 6, characterized in that, The step of responding to a user's selection of a target boot animation in the boot animation selection interface, and writing the target boot animation to the target path through a pre-created target interface, includes: In response to the user's selection of a target boot animation in the boot animation selection interface, a boot animation preview interface is displayed; the boot animation preview interface includes a preview animation control and a confirmation control; In response to the user's operation on the preview animation control, the target boot animation is played on the display screen; In response to the user's operation on the confirmation control, the target boot animation is written to the target path through a pre-created target interface.
8. The display device according to claim 6, characterized in that, After writing the target boot animation to the target path through the pre-created target interface, the following is included: Output a prompt message to inform the user that the boot animation has been successfully set.
9. The display device according to claim 1, characterized in that, The processor is also configured to: In response to a formatting operation input by the user, the boot animation written to the target path is deleted so that the display device plays the default boot animation the next time it is powered on.
10. The display device according to claim 1, characterized in that, The display device is running an Android system, and the target interface is a file writing interface pre-created in the Framework layer of the Android system.
11. A method for setting a boot animation, characterized in that, Applied to the display device according to any one of claims 1-10, the method comprises: A display screen used for displaying images; The processor connected to the display screen is configured to: The target application's interface is displayed on the screen; the target application is used to set the boot animation. In response to a target operation for setting a boot animation, a target boot animation is written to a target path via a pre-created target interface so that the display device plays the target boot animation when it is powered on. The target operation is input on the interface of the target application, and the target path is the highest priority writable path among the paths for loading the boot animation when the display device is powered on.
12. A device for setting a startup animation, characterized in that, include: The display module is used to display the interface of a target application through the display screen of a display device, wherein the target application is an application used for setting boot animation; A processing module is configured to respond to a target operation for setting a boot animation by writing a target boot animation to a target path through a pre-created target interface, so that the display device plays the target boot animation when it boots up; wherein the target operation is input on the interface of the target application, and the target path is the highest priority writable path among the boot animation loading paths when the display device boots up.
13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in claim 11.
14. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of claim 11.