Android system-based startup method, electronic equipment and storage medium

Abstract

The invention discloses a startup method based on an Android system, electronic equipment and a storage medium, and relates to the technical field of intelligent equipment.The method comprises the steps that a startup transition interface module creates a floating window control and sets desktop wallpaper as a background image layer of the floating window control; the display level of the floating window control is higher than that of a native interface of the startup transition interface module; in response to completion of loading of the desktop core resources, the desktop preloading module generates a loading completion signal and sends the loading completion signal to the startup transition interface module, and the startup transition interface module sends a desktop display request to the system activity management service after receiving the loading completion signal and shields the floating window control and a native interface of the startup transition interface module. According to the method and the device, the desktop preloading module and the startup transition interface module are started in parallel when the startup animation is started, the startup transition interface module creates the floating window and takes the desktop wallpaper as a background, so that startup black screen and splash screen can be avoided, and startup visual coherence and user experience are improved.

Description

Technical Field

[0001] This invention relates to the field of smart device technology, and in particular to a boot method, electronic device and storage medium based on the Android system. Background Technology

[0002] With the widespread use of the Android system in smart devices, users have increasingly higher requirements for the smoothness and visual consistency of the boot process. Especially in low- and mid-range smart device scenarios, due to hardware performance limitations, display abnormalities during the boot process are more prominent, seriously affecting the user experience.

[0003] Currently, in the native boot process of Android smart devices, after the boot animation ends and before the desktop is fully loaded, the system will launch a boot transition screen to temporarily occupy the display layer to connect the boot animation and desktop loading stages. However, the native interface of the existing boot transition screen uses a fixed transparent black background. During the gap between the boot animation ending and the desktop loading completion, the direct exposure of the native interface will cause a black screen or screen flickering, thus providing users with a disjointed visual experience. Summary of the Invention

[0004] To address one or more technical problems in the prior art, this invention provides a boot-up method based on the Android system, applicable to smart devices, comprising: The desktop preloading module is started to load the core desktop resources, and the boot transition interface module is started to temporarily occupy the display layer after the boot animation ends; The boot transition interface module creates a floating window control and sets the desktop wallpaper as the background layer of the floating window control. The display layer of the floating window control is higher than the native interface of the boot transition interface module. In response to the completion of loading of the core desktop resources, the desktop preloading module generates a loading completion signal and sends it to the boot transition interface module. After receiving the loading completion signal, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module to display the desktop in the display layer.

[0005] The present invention also provides an electronic device, including a processor and a memory communicatively connected to the processor: The memory stores a boot process based on the Android system, and the boot process based on the Android system is executed by the processor to implement the boot method. The processor is used to call the Android-based boot process in the memory to implement the boot method.

[0006] The present invention also provides a storage medium storing a boot process based on the Android system, wherein the boot process based on the Android system is executed by a processor to implement the boot method.

[0007] The beneficial effects of this invention are: This invention starts the desktop preloading module and the boot transition interface module in parallel during the boot animation. The boot transition interface module creates a floating window with the desktop wallpaper as the background, which can avoid black screen and screen flickering during boot, and improve the visual continuity of boot and user experience. Attached Figure Description

[0008] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0009] Figure 1 This is a flowchart of a power-on method according to an embodiment of the present invention; Figure 2 This is a logic diagram of the power-on method according to an embodiment of the present invention. Detailed Implementation

[0010] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. The embodiments are provided by way of explanation and not by way of limitation. In fact, those skilled in the art will recognize that modifications and variations can be made to the present invention without departing from the scope or spirit thereof. For example, a feature represented or described as part of one embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desirable that the present invention encompass such modifications and variations falling within the scope of the appended claims and their equivalents.

[0011] Example 1: like Figures 1-2 As shown, the present invention provides a power-on method, including: The desktop preloading module is started to load the core desktop resources, and the boot transition interface module is started to temporarily occupy the display layer after the boot animation ends; The boot transition interface module creates a floating window control and sets the desktop wallpaper as the background layer of the floating window control. The display layer of the floating window control is higher than the native interface of the boot transition interface module. In response to the completion of loading of the core desktop resources, the desktop preloading module generates a loading completion signal and sends it to the boot transition interface module. After receiving the loading completion signal, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module to display the desktop in the display layer.

[0012] In practical implementation, the technical solution of this invention can be applied to various Android smart devices, including Android smartphones, Android smart tablets, Android smartwatches, and Android smart TVs. This invention optimizes the boot process, ensuring a seamless transition between the boot animation and the desktop for users of mid-to-low-end devices, avoiding black screen interference and improving the user experience.

[0013] When a user presses the power button on a smart device, the device starts up and enters the boot animation playback phase. The system automatically triggers the startup commands for the desktop preloading module and the boot transition interface module. The core responsibility of the desktop preloading module is to load core desktop resources (including PNG / JPG image files of desktop application icons, and configuration parameters for the number of rows and columns in the desktop grid layout). The core responsibility of the boot transition interface module is to temporarily occupy the screen display layer after the boot animation finishes playing, preventing the display layer from becoming empty.

[0014] After the boot transition interface module starts, it immediately creates a floating window control (Window type TYPE_APPLICATION_OVERLAY) through the Android system's WindowManager interface, and calls the screen capture interface (MediaProjectionAPI) to capture the real-time image of the current desktop wallpaper, setting this image as the background layer of the floating window control. The display layer of this floating window control is ensured to be higher than the native interface of the boot transition interface module (the native interface is the Android system's default transparent black background interface) by setting the zOrderOnTop property of WindowManager.LayoutParams to true.

[0015] After the desktop preloading module completes loading all core desktop resources and writes them to the local cache (e.g., the ` / data / data / com.android.launcher3 / cache` directory), it generates a loading completion signal containing a resource loading checksum and sends it to the boot transition interface module via Android's Binder communication mechanism. Upon receiving this signal, the boot transition interface module sends a desktop display request (`Intent.ACTION_MAIN` + `Intent.CATEGORY_HOME`) through the system activity management service (`ActivityManagerService`), simultaneously calling the `removeView` method of `WindowManager` to disable floating window controls and using the `setVisibility(View.GONE)` method to disable its own native interface.

[0016] In existing technologies, when the desktop has not fully loaded after the boot animation ends, the transparent black background of the native transition interface is exposed, resulting in a black screen or screen flickering. This invention addresses this by using a floating window control to cover the native interface, with the floating window background being the desktop wallpaper, ensuring that the content displayed during the transition phase is consistent with the desktop and avoiding the exposure of the black background. Simultaneously, the desktop preloading module loads core resources in parallel, shortening the desktop readiness time, thus solving the visual disjointness problem from two aspects.

[0017] The direct termination of the boot transition interface module will release all processes and resources of the module. If an abnormality occurs during desktop loading (such as resource loading failure), the display layer will be left without an interface, resulting in a black screen. The shield only hides the interface elements, and the module process continues to run. The floating window can be redisplayed when the desktop loading is abnormal, ensuring that the display layer is always covered with content, while preserving the module's ability to respond to subsequent signals.

[0018] The blocking action of the boot transition interface module can automatically end after the system successfully starts the desktop Activity and completes interface rendering, following the desktop display request sent by the boot transition interface module to the system activity management service. At this time, the desktop Activity occupies the display layer, and the blocked floating window controls and native interface no longer affect the display. The system will release the relevant resources through the memory reclamation mechanism after the desktop is stably displayed.

[0019] The native interface of the boot transition screen module can be Android's native FallbackHome (an Activity with the Home attribute configured in the Settings app). In the stock Android system, when the boot animation plays, the main thread focuses on drawing animation frames and initializing core system services (such as PackageManager and PowerManager), and does not load desktop resources. This is because loading desktop resources (such as app icon decoding and layout calculation) requires a lot of CPU and memory resources. If this is done in parallel with the boot animation, it will cause animation stuttering and affect the visual experience at the beginning of boot.

[0020] The "preloading" function of the desktop preloading module only loads core desktop resources (icons, basic layout) and does not launch the complete desktop process, making it a lightweight resource preparation process. Preloading allows for the early preparation of core resources without affecting the boot animation and system initialization, thus shortening the waiting time for subsequent desktop startup.

[0021] The core function of the boot animation module is to play the startup animation (such as a brand logo animation), providing only visual feedback and lacking resource loading and interface transition capabilities. The core function of the boot transition interface module is to connect the boot animation and the desktop, temporarily occupying the display layer. Directly entering the desktop from the boot animation is not feasible because loading the core desktop resources takes time (typically 2-5 seconds on low-end devices). If the desktop is not ready after the boot animation ends, it will result in a blank display layer and a black screen. The causes of black screens include: low CPU frequency and small memory capacity on low-end devices, resulting in slow decoding and loading speeds of core desktop resources; increased memory fragmentation and decreased resource reading efficiency after long-term use; and excessive resource consumption by system background processes, causing delays in desktop loading threads. This invention solves this problem in two ways: first, the floating window control uses the desktop wallpaper as its background to cover the black background of the native transition interface, avoiding a black screen visual; second, the desktop preloading module loads core resources in parallel, shortening the desktop readiness time and reducing the waiting time during the transition phase.

[0022] Taking a mid-to-low-end smart device running Android 11 (with a Snapdragon 435 CPU and 3GB of RAM) as an example: When the user presses the power button, the device starts up, and the boot animation module begins playing the brand logo animation (lasting 2 seconds). At the same time, the system launches the desktop preloading module and the boot transition interface module.

[0023] The desktop preloading module loads icons (PNG format, 192×192 resolution) of commonly used applications such as WeChat, phone, and SMS, as well as the basic desktop layout (4×5 icon grid) in priority order through a background thread, and writes the loaded resources to the local cache.

[0024] After the boot transition interface module starts, it captures the current desktop wallpaper (a landscape image set by the user) through the MediaProjectionAPI, creates a floating window control with a resolution of 1080×1920, sets the wallpaper image as the background of the floating window, and places the floating window at a higher level than the original black background interface (FallbackHome) of the boot transition interface module.

[0025] After the boot animation ends (2 seconds later), the native interface of the boot transition module (FallbackHome) appears. It is completely covered by a floating window, and the user sees the same wallpaper as the desktop, with no black screen.

[0026] Three seconds later, the desktop preloading module completes the loading of all core resources, generates a loading completion signal containing the icon's MD5 checksum, and sends it to the boot transition interface module via Binder communication.

[0027] After receiving the signal, the boot transition interface module sends a desktop display request to ActivityManagerService, and at the same time calls the removeView method to block the floating window and call setVisibility(View.GONE) to block the native interface.

[0028] The system launches the desktop Activity, directly reads the pre-loaded core resources, and completes the desktop rendering and display within 0.5 seconds, allowing users to experience a smooth transition from the boot animation to the desktop.

[0029] In existing technologies, the boot transition interface of Android smart devices only provides a fixed transparent black background, and the boot animation and desktop loading are executed sequentially (desktop loading only starts after the boot animation ends), with no visual optimization during the transition phase; at the same time, the transition interface and desktop loading are not linked by signal, and the interface only passively exits after the desktop has fully booted up. In the technical solution of this invention, the boot transition interface module and the desktop preloading module start in parallel. The transition interface presents the desktop wallpaper background through a floating window control, and the two are linked by a loading completion signal, enabling precise interface switching.

[0030] Based on this invention, black screen or flickering phenomena between boot animation and desktop loading can be avoided. The floating window background is consistent with the desktop wallpaper, ensuring visual continuity of the boot process and improving user experience. The desktop preloading module loads core resources in parallel, shortening the time interval between desktop startup and display, and reducing user waiting time. The display layer design of the floating window control ensures that the original black background is not exposed, adapting to the hardware performance limitations of low-end and mid-range devices, and expanding the applicability of the technology.

[0031] Example 2: Furthermore, in response to triggering the screen unlock operation, the boot transition interface module initiates the unlock result detection process; When the boot transition interface module receives the loading completion signal and detects that the screen unlock operation has been successfully executed, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and its own native interface.

[0032] Optionally, in response to triggering a screen unlock operation, the boot transition interface module identifies the type of the screen unlock operation, which includes at least one of swipe-up unlock, face unlock, fingerprint unlock, and password unlock. The boot transition interface module executes the corresponding unlock verification process according to the type of unlock operation, including: if it is swipe-up unlock, it obtains the screen touch swipe trajectory by listening to system input events, and determines whether the unlock is successful based on the swipe direction and displacement; if it is face unlock, it calls the face recognition sensor to collect facial feature information and matches it with a preset authorized template; if it is fingerprint unlock, it calls the fingerprint recognition module to collect fingerprint images and compares them with preset authorized fingerprint features; if it is password unlock, it receives the password information entered by the user and performs consistency verification with the authorized password stored in the system.

[0033] Preferably, in response to triggering a screen unlock operation, the boot transition interface module first identifies the type of the screen unlock operation, which includes at least one of swipe-up unlock, face unlock, fingerprint unlock, and password unlock; In response to triggering the swipe-to-unlock operation, the boot transition interface module obtains the sliding trajectory of the screen touch coordinates by listening to system input events. When the difference between the starting and ending vertical coordinates of the sliding trajectory is greater than a preset sliding threshold and the sliding direction is from bottom to top, the swipe-to-unlock operation is determined to be successful. In response to triggering the face unlock operation, the boot transition interface module calls the facial recognition sensor of the smart device to collect facial feature information, and matches the collected facial feature information with the authorized facial feature templates pre-stored in the system. When the number of successfully matched feature points is greater than the preset face matching threshold, the face unlock operation is determined to be successfully executed. In response to triggering a fingerprint unlocking operation, the boot transition interface module calls the fingerprint recognition module of the smart device to obtain fingerprint image data, extracts features from the fingerprint image data, and compares it with the authorized fingerprint feature data stored in the system. When the similarity of the fingerprint features is greater than a preset fingerprint similarity threshold, the fingerprint unlocking operation is determined to be successful. In response to triggering the password unlocking operation, the boot transition interface module receives the password information entered by the user, encrypts the password information, and verifies its consistency with the encrypted authorization password stored in the system. When the verification result is consistent, it is determined that the password unlocking operation was successfully executed. In response to the boot transition interface module receiving the loading completion signal and detecting that the screen unlock operation was successfully executed, the boot transition interface module sends a desktop display request to the system activity management service, and blocks the floating window control and its own native interface in the order that the blocking priority of the floating window control is greater than the blocking priority of the native interface.

[0034] In practice, when a user triggers a screen unlock operation (swipe up to unlock, face unlock, etc.) during the boot-up transition phase, the boot-up transition interface module immediately starts the unlock result detection process, which verifies the validity of the unlock operation by listening to system input events or calling the biometric interface.

[0035] If the boot transition interface module meets two conditions simultaneously: first, it receives a loading completion signal from the desktop preloading module; second, it detects that the unlock operation has been successfully executed, then it sends a desktop display request to the system activity management service and, in accordance with the rule that "the priority of blocking floating window controls is higher than the priority of blocking native interfaces", blocks floating window controls and native interfaces in turn.

[0036] Masking priority refers to the order in which UI elements are hidden. Floating window controls have higher priority, meaning that the masking operation for floating window controls is performed first, followed by the masking operation for the native UI. Because floating window controls are displayed at a higher level than the native UI, if the native UI is masked first, the floating window controls will still remain briefly, and masking the floating window then will result in a brief blank space before the desktop is displayed. If the floating window controls are masked first, the native UI will be exposed, but because the exposure time is extremely short (less than 100 milliseconds) and it is immediately masked, the user will not notice it, ultimately achieving seamless desktop display.

[0037] Take an Android tablet running Android 12 as an example: After the device starts up, a boot animation plays, and the desktop preloading module and boot transition interface module are launched at the same time. The boot transition interface module creates a floating window control, which covers the native interface with the desktop wallpaper as the background.

[0038] After the boot animation ends, the user faces the screen and triggers the face unlock operation. The boot transition interface module calls the facial recognition sensor to collect facial feature information and matches it with the authorized templates pre-stored in the system (if the number of matching feature points is greater than 80%), the unlock is determined to be successful.

[0039] At this point, the desktop preloading module has completed loading the core resources, and the boot transition interface module receives the loading completion signal through Binder communication.

[0040] The boot transition interface module follows a priority rule: first, it calls the WindowManager's removeView method to disable the floating window control (taking 50 milliseconds), then it calls the setVisibility(View.GONE) method to disable the native interface (taking 30 milliseconds), and at the same time, it sends a desktop display request to ActivityManagerService.

[0041] The system desktop Activity starts immediately, reads preloaded resources, and completes the interface rendering within 100 milliseconds, so that the user can see the desktop without any intermediate pause or black screen from the time the user unlocks successfully.

[0042] In existing technologies, screen unlocking and desktop loading are independent of each other. After successful unlocking, the desktop must wait to fully load before it can be displayed, during which time a black background of the transition interface is still exposed. Furthermore, there is no priority design for interface blocking, which often blocks both simultaneously or blocks the native interface first, resulting in a brief blank space before the desktop is displayed. This invention links the unlocking operation with the loading completion signal, triggering desktop display only when both are satisfied, and designs a clear blocking priority order.

[0043] Based on this, the present invention can achieve precise connection between the unlocking operation and the desktop display, avoiding the situation where the desktop still needs to be loaded after unlocking, thus improving the operation response speed; the design of shielding priority eliminates the brief blank or floating window residue during the interface switching process, ensuring visual smoothness; it is compatible with multiple unlocking methods to meet the usage habits of different users and expand the applicable scenarios of the technology.

[0044] Example 3: Furthermore, when the boot transition interface module does not receive the loading completion signal and detects that the screen unlock operation has been successfully executed, the boot transition interface module starts a delayed timing process and a continuous monitoring process. When the timeout period of the delayed timing process expires and the continuous monitoring process fails to capture the loading completion signal, the boot transition interface module terminates the continuous monitoring process, sends a desktop display request to the system activity management service, and blocks the floating window control and its own native interface.

[0045] Optionally, the continuous monitoring process is used to continuously monitor whether the loading completion signal arrives during the delay timing process; wherein, The boot transition interface module starts the continuous monitoring process while starting the delayed timing process. In the continuous monitoring process, a signal monitoring thread and a timing monitoring thread are set. The signal monitoring thread is used to periodically poll to listen for whether the loading completion signal has arrived. The timing monitoring thread is used to monitor the remaining time of the delayed timing process. If the signal listening thread successfully captures the loading completion signal before the timeout period of the delay timeout process expires, the boot transition interface module immediately terminates the delay timeout process and the continuous listening process, sends a desktop display request to the system activity management service, and simultaneously blocks the floating window control and its own native interface to achieve a smooth transition from successful unlocking to desktop display. If the signal listening thread fails to capture the loading completion signal when the delay timer expires, the boot transition interface module determines that the desktop preloading module has encountered an abnormality during the loading process. The abnormality includes, but is not limited to: the desktop icon loading thread is stuck, the desktop layout configuration parameter reading fails, the desktop process does not start normally, insufficient system resources cause the desktop initialization to time out, or the point-to-point communication channel between the desktop and the boot transition interface module is not established or is interrupted. In response to the boot transition interface module determining that an abnormality has occurred in the desktop preloading module during the loading process, the boot transition interface module forcibly terminates the continuous listening process and immediately sends a desktop display request to the system activity management service. At the same time, it blocks the floating window control and its own native interface to prevent the user interface from being in an uninteractive state for a long time due to the abnormal desktop loading.

[0046] Optionally, the timing period of the delayed timing process is 20 to 40 seconds (preferably 30 seconds).

[0047] Optionally, the timing period of the delayed timing process is calculated using the following formula:

[0048] in, Indicates the timing period of the delayed timing process; As the base period; This is the load sensitivity coefficient; The real-time load factor of the system, with a value range of [0, +∞), is calculated using the following formula: ; The habitual attenuation coefficient; The user proficiency factor is calculated using the following formula: ,in The attenuation constant is The average response time for the first swipe-to-unlock after a user's successful boot history is shorter than a threshold. The number of consecutive successes; This is the performance compensation coefficient; The average performance score for the equipment; This is the performance threshold; This represents the minimum backup period under standard operating conditions, ranging from 15 to 25 seconds. This value ensures that even under ideal conditions, the system has sufficient time to complete desktop loading and signal response, preventing frequent triggering of fallback mechanisms due to excessively short periods, which would disrupt the smoothness of the user experience. (Baseline item) The value is 15-25 seconds, which is the "safety base" for the entire cycle. It is based on statistical analysis of desktop loading time on low-end and mid-range devices, ensuring that even under the best conditions, the system will not expose its underlying logic by giving up waiting too early.

[0049] This is a weighting factor used to adjust the impact of real-time device performance load on the cycle time, with a value ranging from 2.0 to 5.0. This factor amplifies the impact of load factors, ensuring that when device performance is severely degraded, it can significantly extend the waiting time, giving the desktop more time to load.

[0050] It is a dimensionless quantity that comprehensively reflects the current CPU utilization rate. ) and memory pressure ( A higher value indicates a busier system, and the longer it may take for the desktop to load. Therefore, it is necessary to extend the loading time. To adapt.

[0051] Load-sensitive items ( This directly addresses the core scenario of this invention—loading lag caused by insufficient resources on low- to mid-range devices. It employs the natural logarithm function ln(1+x) when the load... Starting from 0, this value increases significantly, sensitively responding to deterioration in system condition; however, under very high loads, the logarithmic function prevents this value from expanding indefinitely, avoiding the perception of a system "freezing" due to excessively long waiting times. (Coefficient) This is used to precisely control the strength of this influence.

[0052] It is a weighting coefficient used to adjust the amount of time the user's habits are adjusted for, and its value can range from 3.0 to 8.0. This coefficient determines the system's tolerance for "novice users," and the larger the coefficient, the longer the buffer time reserved for new users.

[0053] It is a dimensionless quantity calculated from historical behavior data, and its value range can be [0,1]. The value can range from 0.05 to 0.2. The value can be taken from 1.5 seconds to 3.0 seconds. The closer the value is to 1, the more skilled the user is and the more likely they are to operate quickly. Therefore, the system will reduce the extra buffer time allocated to them. .

[0054] User habits ( This is key to improving the smoothness of the user experience. It identifies the hesitation and slowness of "novice users" and the pursuit of ultimate speed by "experienced users." It uses historical success rates... To quantify user proficiency And for inexperienced users ( Smaller provides more buffer time ( (Large), effectively preventing interface flickering or frame skipping caused by the system forcibly switching due to timeout while the user is still slowly scrolling up. Coefficient The intensity of the "learning and adaptation" ability was controlled.

[0055] It is a weighting coefficient used for periodic compensation of low-performance devices, and its value can range from 1.0 to 3.0.

[0056] It is a normalized performance score calculated based on hardware parameters such as the number of CPU cores, clock speed, and memory capacity of the device.

[0057] It is a threshold value that distinguishes between low-end and high-end equipment.

[0058] Formula Items This means that only when the device performance is below a threshold ( This option only takes effect when the device is underperforming, providing an extra timeframe to compensate for its inherent slow loading issues.

[0059] Performance compensation items ( This is a compensation measure for the inherent deficiencies in the hardware infrastructure of low- to mid-range devices. It doesn't react only when a problem occurs (such as during a load event), but rather anticipates problems based on the hardware profile from the very beginning of power-on. The worse the performance of the device (…), the more likely it is to cause issues. The smaller The more extra compensation time you get, the more it aligns with the basic principle that "hardware performance is positively correlated with loading time." The max(0,...) function ensures that this only applies to low-end devices and does not affect high-end devices.

[0060] In practical implementation, this invention addresses the scenario where the "boot transition interface module does not receive a loading completion signal but unlocking is successful" by designing a dual mechanism of delayed timing and continuous monitoring. The specific steps are as follows: If the power-on transition interface module detects that the unlocking operation has been successfully executed, but does not receive a loading completion signal, it immediately starts the delayed timing process (e.g., timing period of 20~40 seconds, preferably 30 seconds) and the continuous listening process.

[0061] The continuous monitoring process uses a signal monitoring thread in Binder communication to continuously detect whether the loading completion signal has arrived at a period of 100 milliseconds; the delayed timing process uses a system timer to accumulate the timing time.

[0062] If the timeout period of the delayed timing process expires (e.g., 30 seconds) and the continuous listening process still fails to capture the loading completion signal, the continuous listening process will be terminated, a desktop display request will be sent to the system activity management service, and the floating window control and the native interface will be blocked.

[0063] Taking a mid-to-low-end smart device (2GB RAM) running Android 10 as an example: After the device starts up, a boot animation plays, and the desktop preloading module and boot transition interface module are launched. The boot transition interface module creates a floating window control to cover the native interface.

[0064] After the boot animation ends, the user swipes up to unlock. The boot transition interface module detects that the unlock is successful, but because the background thread of the desktop preloading module is interrupted by system resource scheduling (CPU is occupied by more than 80% of SystemServer), the loading completion signal is not received.

[0065] The boot transition interface module initiates a 30-second delay timer and a continuous monitoring process, with the signal monitoring thread checking the Binder communication channel every 100 milliseconds.

[0066] After the 30-second countdown expires, if the continuous monitoring process still fails to capture the loading completion signal, it is determined that the desktop loading is abnormal. The boot transition interface module terminates the continuous monitoring process, calls the removeView method to disable the floating window control, calls setVisibility(View.GONE) to disable the native interface, and sends a desktop display request to ActivityManagerService.

[0067] When the system launches the desktop Activity, the desktop loads basic resources in real time (although slower than preloading, it can still be displayed normally), preventing the user interface from being in an uninteractive state for a long time.

[0068] In existing technologies, if the desktop loading fails, the boot transition screen remains displayed until the system is forcibly terminated, resulting in a prolonged period of uninterrupted user interface interaction. Furthermore, the lack of a delay timer and continuous monitoring mechanism makes it impossible to proactively address loading failure scenarios. This invention designs a combined delay timer and continuous monitoring mechanism that proactively triggers desktop display upon loading failure, preventing the interface from freezing.

[0069] Based on this, the present invention can avoid prolonged uninteractive interface due to abnormal desktop loading, ensuring that users can use the device normally; the design of the delayed timing cycle balances loading waiting time and user experience, reserving sufficient time for desktop loading while avoiding excessive waiting; the continuous monitoring process can capture loading completion signals in real time, and can still achieve smooth transition when the abnormality is resolved, taking into account both normal and abnormal scenarios.

[0070] Example 4: Furthermore, when the continuous monitoring process captures the loading completion signal before the timeout of the delayed timing process, the boot transition interface module terminates the delayed timing process, and at the same time sends a desktop display request to the system activity management service and blocks the floating window control and its own native interface.

[0071] In practical implementation, this invention optimizes the process response logic for scenarios where a loading completion signal is captured during the delay timer. The specific steps are as follows: After the boot transition interface module starts the delayed timing process and the continuous listening process, before the timing period expires (e.g., within 30 seconds), the continuous listening process captures the loading completion signal sent by the desktop preloading module through the signal listening thread.

[0072] At this point, the boot transition interface module immediately calls the cancel method of the system timer to terminate the delayed timing process and prevent the timing from continuing; at the same time, it sends a desktop display request to the system activity management service, and blocks the floating window control and the native interface according to the priority of the floating window control.

[0073] Taking Android smart devices running Android 13 as an example: After the device starts up, a boot animation plays, and the desktop preloading module and boot transition interface module are launched. The boot transition interface module creates a floating window control, which covers the native interface with the desktop wallpaper as the background.

[0074] After the boot animation ends, the user presses the fingerprint sensor to unlock. The boot transition interface module detects that the unlock is successful, but does not receive a loading completion signal, and then starts a 30-second delay timer and continuous monitoring process.

[0075] When the delay timer reaches 15 seconds, the desktop preloading module completes the loading of core resources and sends a loading completion signal via Binder communication. The continuous listening process of the boot transition interface module captures this signal.

[0076] The boot transition interface module immediately terminates the delayed timing process, first blocking the floating window control, then blocking the native interface, and sending a desktop display request to ActivityManagerService. The system desktop Activity starts and is displayed. The time from signal capture to desktop display is 120 milliseconds.

[0077] In existing technologies, even after the desktop has finished loading, the desktop display is only triggered after the delay timer period expires, resulting in excessively long waiting times for users; or there is no delay timer termination mechanism, with timing and monitoring running independently, leading to wasted resources. This invention, upon capturing the loading completion signal, immediately terminates the delay timer, enabling real-time desktop display.

[0078] Based on this, the present invention can reduce unnecessary waiting time for users, display the desktop immediately after loading, and improve the smoothness of operation; terminating the delayed timing process can release system timer resources and reduce device power consumption; it takes into account both fast and slow loading scenarios, and can trigger desktop display at the optimal time no matter when loading is completed.

[0079] Example 5: Furthermore, the startup desktop preloading module for loading core desktop resources includes: The desktop preloading module asynchronously loads the core desktop resources in priority order through a background loading thread independent of the main thread. The core desktop resources include image files of desktop application icons and desktop layout configuration parameters.

[0080] Optionally, when loading the core desktop resources, the desktop preloading module loads them asynchronously through a background loading thread independent of the main thread. The main thread is the core thread responsible for handling user interface rendering, system service initialization, and user input response during system startup. The background loading thread is an independent thread created by the desktop preloading module at startup through a thread pool mechanism. The priority of the background loading thread is set to be lower than the main thread but higher than ordinary background threads to ensure that the loading of the core desktop resources is completed first without affecting the smoothness of system startup.

[0081] Preferably, during the loading process, the background loading thread loads the desktop core resources in order of priority. The priority order is determined by the probability that the resource will be interacted with by the user for the first time, including: desktop application icon image files have the highest priority, and desktop layout configuration parameters have the next highest priority. When loading each type of resource, the background loading thread adopts a combination of segmented loading and cache writing, including: dividing each type of resource into multiple resource sub-packages; immediately writing each resource sub-package into the local cache area and updating the loading progress flag after loading is completed; the loading progress flag is used to report the current loading progress to the desktop preloading module. After the desktop preloading module detects that the local cache of all desktop core resources has been written, it generates the loading completion signal and sends the loading completion signal to the boot transition interface module through a point-to-point communication mechanism.

[0082] Through the above asynchronous loading mechanism, the desktop preloading module can complete the loading and caching of core desktop resources in advance without blocking the main thread, thereby significantly shortening the time interval from successful unlocking to full desktop display. This avoids interface lag or black screen caused by the main thread being occupied by resource loading, and improves the overall smoothness and response speed in the initial swipe-up unlocking scenario.

[0083] In practice, the core desktop resources include: image files of desktop application icons (PNG and JPG formats, including versions adapted to different resolutions) and desktop layout configuration parameters (number of rows and columns of icon grid, icon spacing, dock position, etc., stored in XML files).

[0084] After the desktop preloading module starts, a background loading thread independent of the main thread is created through the thread pool. The priority of this thread is set to THREAD_PRIORITY_BACKGROUND+1 (lower than THREAD_PRIORITY_FOREGROUND of the main thread, and higher than THREAD_PRIORITY_LOWEST of ordinary background threads) by the android.os.Process.setThreadPriority method.

[0085] The background loading thread loads the core desktop resources asynchronously in the order of "application icon image files first, layout configuration parameters second": first load the icons of frequently used applications (such as phone, WeChat, and browser), then load the icons of less frequently used applications, and finally load the layout configuration parameters.

[0086] During the loading process, the background loading thread reads the resource files through FileInputStream, decodes them, and writes them to the local cache directory. At the same time, it monitors the loading progress through ProgressMonitor. When all resources have been written to the cache, the desktop preloading module generates a loading completion signal.

[0087] Main thread: also known as UI thread, is the core thread (process name android.ui) created when the Android system starts. It is responsible for handling key tasks such as user interface rendering (such as boot animation frame rendering), system service initialization (such as PackageManager, ActivityManager), and user input response (such as touch event handling). The smooth operation of the main thread directly affects the stability of the boot process and the visual experience.

[0088] Background loading thread: This is an independent thread created by the desktop preloading module through java.util.concurrent.ExecutorService. It is only responsible for loading and caching the core desktop resources and does not participate in UI rendering or system service initialization. Its running state does not affect the normal operation of the main thread.

[0089] Taking a mid-to-low-end smart device running Android 9 (with a MediaTek MT6737 CPU and 2GB of RAM) as an example: After the device starts up, the main thread starts and plays the boot animation (30fps), while the PackageManager service is initialized to handle system permission configuration.

[0090] The desktop preloading module creates a background loading thread through a thread pool, with a priority set to THREAD_PRIORITY_BACKGROUND+1. This thread begins loading core desktop resources. First, it reads the icon files (PNG format, 144×144 resolution) of 10 commonly used applications such as WeChat, phone, and SMS in the / data / app directory, decodes them using BitmapFactory.decodeFile, and writes them to the / data / data / com.android.launcher3 / cache / icon directory, which takes 1.2 seconds. Then, the icon files of the remaining 20 less frequently used applications are read, decoded, and written to the cache, which takes 0.8 seconds. Finally, the layout configuration file (launcher_layout.xml) in the / data / data / com.android.launcher3 / shared_prefs directory is read, the 4×5 icon grid parameters are parsed, and written to the cache, which takes 0.3 seconds.

[0091] After all resources have been written to the cache, the background loading thread reports the loading completion status through ProgressMonitor, and the desktop preloading module generates a loading completion signal containing the total number of resources (31) and the cache path.

[0092] In existing technologies, desktop resource loading begins after the boot animation ends and is executed on the main thread, leading to excessive load on the main thread, animation stuttering, or slow desktop loading. Furthermore, loading lacks priority order, with all resources loading synchronously, further extending loading time. This invention employs a background asynchronous loading method, independent of the main thread, and loads resources according to their usage priority, while generating a signal upon completion of cache writing.

[0093] Based on this, the present invention can load resources in the background without occupying the main thread resources, ensuring smooth playback of the boot animation and normal initialization of system services; load resources according to priority, with frequently used application icons ready first, shortening the waiting time for the first interaction on the desktop; write resources to the cache after loading, and the subsequent desktop startup can directly read the cache, improving the speed of the second boot; the loading progress monitoring mechanism ensures the accuracy of the loading completion signal and avoids abnormal desktop display caused by incomplete resource loading.

[0094] Example 6: Furthermore, the desktop preloading module generates a loading completion signal and sends it to the boot transition interface module, including: the desktop preloading module sends the loading completion signal to the boot transition interface module through point-to-point communication; After receiving the loading completion signal, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module. This includes: the boot transition interface module verifies the loading completion signal; after the loading completion signal is verified, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module.

[0095] In practice, after the desktop preloading module generates a loading completion signal, it sends the signal to the boot transition interface module via point-to-point communication (such as Android Binder communication). The signal content includes: resource checksum (a string concatenated with the MD5 values ​​of all core resources), loading completion timestamp, and total number of resources.

[0096] After receiving the loading completion signal via the Binder interface, the boot transition interface module initiates the signal verification process: Verify the validity of the timestamp: the difference between the timestamp and the current system time should not exceed 5 seconds (to avoid receiving expired signals); Verify the consistency of the total number of resources: The total number of resources in the signal is consistent with the total number of desktop core resources pre-stored in the boot transition interface module (e.g., 31). Verify the correctness of the resource checksum: The boot transition interface module calculates the MD5 value of the loaded resources in the local cache and compares it with the checksum in the signal. If they match, the verification passes.

[0097] After successful verification, the boot transition interface module sends a desktop display request to the system activity management service, while simultaneously blocking the floating window control and the native interface.

[0098] Take an Android tablet running Android 11 as an example: After the desktop preloading module completes the loading of 31 core resources, it generates a loading completion signal: the timestamp (Unix timestamp) is 1699999999000 (the current system time is 1699999999000), the total number of resources is 31, and the resource checksum is "md5_icon1+md5_icon2+...+md5_layout".

[0099] The desktop preloading module sends a signal to the FallbackHome module (boot transition interface module) via the send method of Binder communication.

[0100] After receiving the signal, the power-on transition interface module initiates verification: The timestamp difference is calculated as: 1699999999000 - 1699999999000 = 0 seconds, which meets the requirements. The total number of resources, 31, is the same as the total number of pre-deposited resources; Read the files of 31 resources in the local cache, calculate the MD5 value and concatenate the string. The string is completely consistent with the checksum in the signal, and the verification passes.

[0101] The boot transition interface module sends a desktop display request to ActivityManagerService, blocking floating window controls and the native interface, and the desktop is displayed smoothly.

[0102] In existing technologies, after the desktop loads, a notification signal without verification is sent directly, or no signal is sent at all. The boot transition interface module responds blindly, which can easily lead to abnormal desktop display due to expired, incorrect, or forged signals (such as triggering display before resources are fully loaded, resulting in missing icons). This invention uses point-to-point communication to transmit signals and designs a triple verification mechanism of timestamp, total number of resources, and checksum. The point-to-point communication method ensures the accuracy and security of signal transmission, preventing signals from being intercepted or tampered with by other processes; the triple verification mechanism excludes expired, incorrect, or forged signals, ensuring that the boot transition interface module only triggers desktop display after the core desktop resources are fully and correctly loaded; this reduces desktop display errors caused by abnormal signals (such as missing icons or disordered layout), and improves the stability and reliability of the boot process.

[0103] Example 7: Further, setting the desktop wallpaper as the background layer of the floating window control includes: The boot transition interface module takes a real-time screenshot of the current desktop wallpaper of the smart device to capture the latest displayed image of the desktop wallpaper. The boot transition interface module sets the latest displayed image as the background layer of the floating window control.

[0104] Optionally, when the boot transition interface module takes a real-time screenshot of the current desktop wallpaper of the smart device, it determines the type of the current desktop wallpaper, which includes static wallpaper, live wallpaper, real-time weather live wallpaper, and clock live wallpaper; wherein, When the current desktop wallpaper is determined to be a static wallpaper, the boot transition interface module reads the static image data of the current frame through the display buffer and sets it directly as the screenshot result as the background layer of the floating window control; When the current desktop wallpaper is determined to be a live wallpaper, the boot transition interface module starts a short-time image capture window before taking a screenshot. The duration of the short-time image capture window is set to a first time (e.g., 500 milliseconds). During the first time, multiple frames of images are continuously captured at intervals of 100 milliseconds per unit time. The captured multiple frames of images are then processed by image fusion to generate a representative fused image. The fused image is used to reflect the visual state of the live wallpaper at the moment of unlocking. The fused image is then set as the background layer of the floating window control. When the current desktop wallpaper is determined to be a real-time weather live wallpaper, the boot transition interface module first reads the current weather status data provided by the system weather service interface before taking a screenshot. The current weather status data includes weather type, temperature, wind speed, and day / night status. The boot transition interface module determines the image rendering status of the current live wallpaper based on the weather status data, and performs a single-frame screenshot operation at the second time (e.g., 300 milliseconds) after the image rendering status stabilizes, to ensure that the screenshot image is highly consistent with the current weather status and avoid image misalignment or visual fragmentation caused by changes in dynamic elements. When the current desktop wallpaper is determined to be a clock live wallpaper, the boot transition interface module reads the current time data provided by the system time service interface before taking a screenshot, and determines whether the current time is at the minute switching threshold. If it is at the threshold, the screenshot operation is delayed until the third time after the minute switching is completed (e.g., 200 milliseconds) to ensure that the clock display content in the screenshot image is complete, clear and without jumps.

[0105] By employing the differentiated screenshot strategies for different types of desktop wallpapers, the boot transition interface module can present image content in the background of the floating window control that is highly consistent with the actual state of the current desktop, avoiding visual inconsistency or image distortion caused by differences in wallpaper types, thereby enhancing the user's immersive and consistent experience during the initial swipe-to-unlock process upon booting up.

[0106] In practice, after the boot transition interface module starts, it first uses the WallpaperManager interface to determine the type of the current desktop wallpaper: static wallpaper, live wallpaper, real-time weather live wallpaper, and clock live wallpaper, and then performs a screenshot operation for different types of wallpapers. Static wallpapers (e.g., landscape images in JPG format): The current frame is read from the screen display buffer via the MediaProjection API, directly obtaining the static image data without additional processing. Dynamic wallpapers (e.g., looping animations): A short image capture window of 500 milliseconds is initiated, capturing one frame every 100 milliseconds for a total of 5 frames. An image fusion algorithm (e.g., weighted average) is used to merge the 5 frames into one frame, preserving the core visual elements of the dynamic wallpaper. Real-time weather dynamic wallpapers (e.g., animations displaying rain or sunshine): The WeatherManager interface is first called to read the current weather status (e.g., light rain, 25℃, daytime). After the wallpaper animation renders and stabilizes (300 milliseconds), a single-frame screenshot is executed, ensuring the screenshot image matches the weather status. Clock dynamic wallpapers (e.g., real-time updating digital clocks): The TimeManager interface is called to read the current time (e.g., 14:59:59). It is determined to be at the minute switching threshold, and after a 200-millisecond delay until 15:00:00, a screenshot is executed, ensuring the clock is displayed completely. The image data obtained from the screenshot is set as the background layer of the floating window control.

[0107] The system folder stores the original wallpaper files (such as JPG files for static wallpapers and APK files for live wallpapers), not the real-time image currently displayed on the screen. For example, if a user has just changed their wallpaper, the system folder may not be updated in time and will retrieve the old wallpaper; the original file of a live wallpaper cannot directly extract the current frame image, requiring the wallpaper process to run to display, which consumes significant resources. The screenshot method directly captures the real-time image of the screen display buffer, ensuring that the floating window background is completely consistent with the current desktop wallpaper, avoiding visual disjointedness caused by untimely wallpaper updates or type differences.

[0108] Taking mid-to-low-end smart devices running Android 12 as an example: The user set their desktop wallpaper to a live weather wallpaper, and the current weather condition is light rain and daytime.

[0109] After the device starts up, the boot transition interface module starts, and the WallpaperManager interface determines that the wallpaper type is a real-time weather live wallpaper.

[0110] The startup transition interface module calls the WeatherManager interface to read weather data: weather type: light rain, temperature: 25℃, day / night status: daytime.

[0111] Wait 300 milliseconds to ensure the wallpaper's rain animation rendering is stable (to avoid raindrop position misalignment), then call the MediaProjectionAPI to perform a single-frame screenshot and obtain a real-time wallpaper image at a resolution of 1080×1920 (including raindrop animation and daytime scene).

[0112] Set the image as the background layer of the floating window control. The floating window will cover the original interface of the boot transition interface module, so that the transition interface seen by the user is completely consistent with the desktop wallpaper.

[0113] In existing technologies, the background of the boot transition interface is a fixed color or static image, unrelated to the desktop wallpaper, resulting in visual discontinuity; furthermore, no adaptation scheme is designed for different types of wallpapers, and if the desktop is a dynamic wallpaper, the transition interface cannot present a consistent visual effect. This invention obtains wallpaper images through real-time screenshots and designs differentiated screenshot strategies for different wallpaper types.

[0114] Based on this, the present invention enables the floating window background to be synchronized with the desktop wallpaper in real time, ensuring visual consistency with the desktop during the boot transition and eliminating the sense of disconnect; the differentiated screenshot strategy adapts to various wallpaper types, avoiding image distortion or display abnormalities caused by dynamic changes and status updates of the wallpaper; the screenshot method does not require running an additional wallpaper process, consumes low resources, and adapts to the hardware performance limitations of low-end and mid-range devices.

[0115] Example 8: Further, setting the desktop wallpaper as the background layer of the floating window control includes: The boot transition interface module calls the screen display interface of the smart device to read the screen's native resolution parameters, sets the resolution of the floating window control to be consistent with the screen's native resolution, and the display range of the floating window control covers the entire screen display area.

[0116] In specific implementation, for example, considering the screen characteristics of Android tablets (such as the common 16:10 / 4:3 aspect ratio, and the use of HD+ / WUXGA native resolution in mid-to-low-end devices), the execution logic of the boot transition interface module is as follows: After the boot transition interface module creates the floating window control, it first calls the getDisplayInfo(Display.DEFAULT_DISPLAY) method through the DisplayManager interface of the Android system to read the native screen resolution parameters of the tablet. Here, the "native screen resolution" refers to the resolution of the tablet screen hardware physical pixel dimension (such as 1280×800 pixels, corresponding to HD+ level, or 1920×1200 pixels, corresponding to WUXGA level, which is common in mid-to-low-end Android tablets), rather than the "logical resolution" adapted by the system based on DPI (pixel density) (for example, if a tablet's native resolution is 1280×800, and the DPI is set to 160, the system's logical resolution may be mapped to 1024×640 pixels. If the floating window is set directly using the logical resolution, it will cause image stretching).

[0117] Subsequently, the boot transition interface module configures the size attributes of the floating window control through the WindowManager.LayoutParams object: setting layoutParams.width and layoutParams.height to the read native screen resolution values ​​(for example, a tablet with a native resolution of 1280×800 pixels would have its floating window width and height set to 1280 pixels and 800 pixels respectively); simultaneously, the layout parameters layoutParams.width and layoutParams.height of the floating window are additionally specified as WindowManager.LayoutParams.MATCH_PARENT to ensure that the display area of ​​the floating window control perfectly matches the physical size of the tablet screen—even if the tablet has a reserved area for the status bar / navigation bar due to system settings, MATCH_PARENT can still block the system default margins (additional settings required). `layoutParams.flags=WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS` prevents floating windows from having blank spaces at the top / bottom, thus achieving full coverage of the screen display area.

[0118] Taking a mid-to-low-end Android tablet running Android 12 (10.1-inch screen with a native resolution of 1280×800 pixels, 16:10 aspect ratio, and a MediaTek MT8768 processor) as an example: After the tablet is powered on and starts up, when the boot animation (brand logo animation, lasting 4 seconds) plays for 2 seconds, the system triggers the boot transition interface module to start. This module first creates a floating window control (Window type TYPE_APPLICATION_OVERLAY). The boot transition interface module calls the getDisplayInfo method of DisplayManager to read the native resolution parameters of the tablet screen as "width 1280 pixels, height 800 pixels", confirming that the current screen orientation is portrait (the tablet boots up in portrait mode by default), thus eliminating resolution deviation caused by orientation switching; Set the floating window properties using WindowManager.LayoutParams: layoutParams.width=1280, layoutParams.height=800. Also, set layoutParams.width and layoutParams.height to MATCH_PARENT and add the FLAG_LAYOUT_NO_LIMITS flag to hide the 24-pixel height area reserved for the status bar. The boot transition interface module had previously captured the tablet's current desktop wallpaper (a static plant wallpaper set by the user, with a resolution of 1280×800 pixels) via the MediaProjectionAPI. At this time, the wallpaper image is set as the floating window background. Because the floating window resolution is completely consistent with the wallpaper resolution and the screen's native resolution, the wallpaper does not need to be stretched or cropped, and the image details (such as leaf textures) are fully presented. After the boot animation ends (4 seconds), the floating window controls of the boot transition interface module completely cover the tablet screen without any border gaps or blank spaces, and the transition interface seen by the user is completely consistent with the visual effect of the subsequent desktop.

[0119] Example 9: The present invention also provides an electronic device, including a processor and a memory communicatively connected to the processor: The memory stores a boot process based on the Android system, and the boot process based on the Android system is executed by the processor to implement the boot method. The processor is used to call the Android-based boot process in the memory to implement the boot method.

[0120] In practical implementation, the hardware structure of this electronic device includes a processor and a memory, which are connected via a bus (such as a PCIe bus). The memory can be flash memory (such as eMMC 5.1), storing a boot process based on the Android system (stored in APK format, package name com.android.bootprocess). This program contains the core code of the desktop preloading module and the boot transition interface module, as well as functional modules such as signal transmission, floating window creation, and resolution adaptation. The processor can be an ARM architecture CPU (such as a Snapdragon 480), responsible for calling the boot process in the memory and executing the boot process according to the steps of the boot method described above. After the device is powered on, the processor initializes the system bus and memory, and reads the boot process; it starts the boot animation module, and simultaneously calls the desktop preloading module and the boot transition interface module; it controls the boot transition interface module to create a floating window control, and sets the wallpaper background and resolution; it controls the desktop preloading module to load core resources through a background thread and generate a loading completion signal; after receiving and verifying the signal, it controls the boot transition interface module to block the floating window and the native interface, and starts the desktop Activity.

[0121] Example 10: The present invention also provides a storage medium storing a boot process based on the Android system, wherein the boot process based on the Android system is executed by a processor to implement the boot method.

[0122] In specific implementation, the storage medium is a computer-readable storage medium, including but not limited to: USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), solid-state drive (SSD), optical disc (CD-ROM), etc. The boot process program based on the Android system stored in the storage medium can be written in Java, compiled to generate a DEX file, containing the code logic corresponding to all execution steps of the boot method: module startup logic, floating window creation and background setting logic, resource preloading logic, signal transmission and verification logic, masking logic, etc.

[0123] When the storage medium is connected to an Android smart device (such as a USB flash drive inserted into the device's USB port), the device's processor reads the boot process from the storage medium through a file reading interface (such as a USB Host controller), loads it into the device's memory, and executes it to implement the corresponding boot method.

[0124] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A boot method based on the Android system, applied to smart devices, characterized in that, include: The desktop preloading module is started to load the core desktop resources, and the boot transition interface module is started to temporarily occupy the display layer after the boot animation ends; The boot transition interface module creates a floating window control and sets the desktop wallpaper as the background layer of the floating window control. The display layer of the floating window control is higher than the native interface of the boot transition interface module. In response to the completion of loading of the core desktop resources, the desktop preloading module generates a loading completion signal and sends it to the boot transition interface module. After receiving the loading completion signal, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module to display the desktop in the display layer.

2. The power-on method according to claim 1, characterized in that: In response to triggering the screen unlock operation, the boot transition interface module initiates the unlock result detection process; When the boot transition interface module receives the loading completion signal and detects that the screen unlock operation has been successfully executed, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and its own native interface.

3. The power-on method according to claim 2, characterized in that: When the boot transition interface module does not receive the loading completion signal and detects that the screen unlock operation is successfully executed, the boot transition interface module starts the delay timer process and the continuous monitoring process. When the timeout period of the delayed timing process expires and the continuous monitoring process fails to capture the loading completion signal, the boot transition interface module terminates the continuous monitoring process, sends a desktop display request to the system activity management service, and blocks the floating window control and its own native interface.

4. The power-on method according to claim 3, characterized in that: When the continuous monitoring process captures the loading completion signal before the timeout of the delayed timeout process, the boot transition interface module terminates the delayed timeout process, and at the same time sends a desktop display request to the system activity management service and blocks the floating window control and its own native interface.

5. The power-on method according to claim 1, characterized in that, The startup desktop preloading module loads core desktop resources, including: The desktop preloading module asynchronously loads the core desktop resources in priority order through a background loading thread independent of the main thread. The core desktop resources include image files of desktop application icons and desktop layout configuration parameters.

6. The power-on method according to claim 1, characterized in that: The desktop preloading module generates a loading completion signal and sends it to the boot transition interface module, including: the desktop preloading module sends the loading completion signal to the boot transition interface module through point-to-point communication; After receiving the loading completion signal, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module. This includes: the boot transition interface module verifies the loading completion signal; after the loading completion signal is verified, the boot transition interface module sends a desktop display request to the system activity management service and blocks the floating window control and the native interface of the boot transition interface module.

7. The power-on method according to claim 1, characterized in that, Setting the desktop wallpaper as the background layer of the floating window control includes: The boot transition interface module takes a real-time screenshot of the current desktop wallpaper of the smart device to capture the latest displayed image of the desktop wallpaper. The boot transition interface module sets the latest displayed image as the background layer of the floating window control.

8. The power-on method according to claim 7, characterized in that, Setting the desktop wallpaper as the background layer of the floating window control further includes: The boot transition interface module calls the screen display interface of the smart device to read the screen's native resolution parameters, sets the resolution of the floating window control to be consistent with the screen's native resolution, and the display range of the floating window control covers the entire screen display area.

9. An electronic device, comprising a processor and a memory communicatively connected to the processor, characterized in that: The memory stores a boot process based on the Android system, and when the processor executes the boot process based on the Android system, it implements the boot method as described in any one of claims 1 to 8. The processor is used to call the Android-based boot process in the memory to implement the boot method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium stores a boot process based on the Android system, which, when executed by the processor, implements the boot method according to any one of claims 1 to 8.

Images