Android boot method supporting multi-client differentiated customization

Abstract

This invention provides an Android boot method supporting multi-customer differentiated customization, comprising: adding a new customer-customized partition in the Android system's storage partition architecture, namely a "custom" partition and a "custom_logo" partition; burning the corresponding customer's customized resource package to the "custom" partition and the "custom_logo" partition in a differentiated manner; after power-on, detecting and loading / displaying the customized boot logo image in the "custom_logo" partition; loading the customized boot animation file in the "custom" partition; after booting to the desktop, scanning the customized Android application installation package in the preset APK storage directory in the "custom" partition, and completing the application installation according to the customer's preset strategy. This invention overcomes the shortcomings of low efficiency and high maintenance costs in current multi-customer differentiated customization methods.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an Android startup method that supports multi-customer differentiated customization. Background Technology

[0002] With the widespread adoption of smart terminal devices, the Android system, due to its open-source nature, is widely used in various terminal products. Customers in different industries (such as finance, education, and industrial control) have increasingly demanding customization of Android terminals, particularly in areas such as boot logos, startup processes, and pre-installed applications. For example, financial institutions require a unique brand logo and security authentication animation to be displayed upon terminal startup, education customers need pre-installed customized educational applications, and industrial customers may require a simplified startup process and the loading of specific control programs.

[0003] Currently, the main shortcomings of the methods for implementing multi-customer differentiated customization are as follows:

[0004] Maintaining separate Android system images for different clients and implementing customizations by modifying system source code or resource files leads to a proliferation of system image versions, increasing R&D and maintenance costs. Furthermore, changes in client requirements necessitate recompiling the entire system, resulting in low iteration efficiency.

[0005] Based on a general system, custom resources are added to different customers using flashing tools or scripts. Due to the lack of unified custom partition management, custom resources are prone to conflicts with system files and are at risk of being tampered with. At the same time, it cannot be guaranteed that custom resources will be loaded first during the boot process (such as the BootLoader period).

[0006] Implementing some customized functions solely through pre-installed applications cannot meet the customization requirements of underlying startup processes such as boot logos and boot animations. Furthermore, customized applications have low coupling with the system, making them easy for users to uninstall or disable, thus compromising the stability of the customization effect. Summary of the Invention

[0007] The main objective of this invention is to provide an Android startup method that supports multi-customer differentiated customization, aiming to overcome the shortcomings of low efficiency and high maintenance costs in current multi-customer differentiated customization.

[0008] To achieve the above objectives, the present invention provides an Android startup method that supports multi-customer differentiated customization, comprising the following steps:

[0009] In the storage partitioning architecture of the Android system, two new independent customer-customized partitions have been added, namely the custom partition and the custom_logo partition.

[0010] During the factory production stage of Android terminal devices, the customized resource packages corresponding to the customer are burned into the custom partition and the custom_logo partition in a differentiated manner; wherein, the customized resource packages correspond one-to-one with the customer's customization requirements; the custom partition is used to store the customer's exclusive customized boot animation files and customized Android application installation packages, and the custom_logo partition is used to store the customer's exclusive customized boot logo image;

[0011] After the Android terminal device is powered on, the BootLoader is triggered to detect the customized boot logo image in the custom_logo partition and load and display it on the screen.

[0012] The preset animation loading module is invoked to load the customized boot animation file in the custom partition and execute the boot animation display process;

[0013] After the Android system boots up and enters the desktop, it scans the customized Android application installation packages in the preset APK storage directory within the custom partition and completes the application installation according to the customer's preset strategy.

[0014] Furthermore, if the BootLoader does not detect a customized boot logo image, it loads the default Android system boot logo image.

[0015] If the preset animation loading module does not detect the customized boot animation file, the default Android system boot animation file will be loaded.

[0016] Furthermore, the method also includes:

[0017] Read the preset customer-specific custom prop parameters in the Android system's build.prop configuration file, parse the values ​​of each parameter, and execute the corresponding system function differentiation process according to the parameter values; at least including hiding the Google Play app icon, disabling Google Play services from starting in the background, and loading customer-specific UI resource files stored in the custom partition.

[0018] Furthermore, before completing the application installation according to the customer's preset strategy, the following steps are included:

[0019] The system performs signature and integrity verification on customized Android application installation packages. Once the verification is successful, the application is installed according to the customer's preset strategy, and the application is automatically launched or waits for the user to launch it manually based on the startup configuration.

[0020] Furthermore, two new independent, custom-designed partitions have been added to the Android system's storage partition architecture, including:

[0021] Using the Android system partitioning tool, two custom partitions with configurable capacity, custom_logo and custom_logo, are created in the eMMC / NAND Flash storage medium of the Android terminal device. Mount information for these two custom partitions is then added to the fstab configuration file of the Android system.

[0022] Furthermore, when an Android terminal device needs to change to meet customer customization requirements, the original files in the custom partition and custom_logo partition are erased through system recovery mode or factory flashing tools, and the new customized resource package for the customer is re-flashed.

[0023] Furthermore, the method also includes:

[0024] Collect data throughout the entire lifecycle of Android terminal devices; obtain customized trend data from clients in the same industry;

[0025] Analyze the entire lifecycle data and customization trend data to predict customers' potential customization needs for the future preset cycle;

[0026] Based on potential customization needs, pre-adapted resource operations are automatically performed during idle periods on Android terminal devices; when customers raise actual customization needs, pre-adapted resources are directly invoked to complete rapid deployment.

[0027] Furthermore, the full lifecycle data includes historical startup logs, customer-customized resource iteration records, and hardware wear parameters such as storage read / write counts and screen brightness decay values.

[0028] Pre-adaptation of resources includes: if it is predicted that 4K animation support is required, then a 4K animation format conversion tool and adaptation template are generated in advance in the custom partition; if it is predicted that lightweight application is required, then the corresponding customer's application lightweight patch package is downloaded and stored in a subdirectory of the custom partition.

[0029] Furthermore, the method also includes:

[0030] When the Android system boots up for the first time, it generates a unique fingerprint for the Android terminal device, binds the unique fingerprint to the customer's digital certificate, stores it in the custom partition directory, and uploads it to the cloud security database.

[0031] Establish a baseline for the startup behavior of Android terminal devices, including CPU usage curves, memory loading rates, and frequency of access to custom partition files during normal startup.

[0032] During each startup process, the current startup behavior is compared with the startup behavior baseline in real time. If an anomaly is detected, a security protection mechanism is immediately triggered. The security protection mechanism includes pausing the loading of customized resources, locking access permissions to the custom partition, and prompting the administrator to perform device unique fingerprint verification via a local pop-up window on the Android terminal device.

[0033] Furthermore, when a customer changes their customization requirements and needs to re-flash resources, the administrator is required to provide both the new customer's digital certificate and the device's unique fingerprint in the cloud security database for dual verification. Only after successful dual verification is it allowed to erase the original files in the custom partition and the custom_logo partition.

[0034] The present invention also provides an Android boot device that supports multi-customer differentiated customization, comprising:

[0035] A new module has been added to add two independent customer-customized partitions in the Android system's storage partition architecture: the custom partition and the custom_logo partition.

[0036] The burning module is used to burn customized resource packages corresponding to customers into the custom partition and the custom_logo partition during the factory production stage of Android terminal devices. The customized resource packages correspond one-to-one with the customer's customization requirements. The custom partition is used to store the customer's customized boot animation files and customized Android application installation packages, and the custom_logo partition is used to store the customer's customized boot logo image.

[0037] The first loading module is used to trigger the BootLoader program to detect the customized boot logo image in the custom_logo partition and load and display it on the screen after the Android terminal device is powered on.

[0038] The second loading module is used to call the preset animation loading module, load the customized boot animation file in the custom partition, and execute the boot animation display process;

[0039] The installation module is used to scan the customized Android application installation packages in the preset APK storage directory in the custom partition after the Android system has finished booting and entered the desktop, and complete the application installation according to the customer's preset strategy.

[0040] The present invention provides an Android boot method supporting multi-customer differentiated customization, comprising: adding two independent customer-customized partitions in the storage partition architecture of the Android system, namely a custom partition and a custom_logo partition; during the factory production stage of the Android terminal device, burning the customized resource package corresponding to the customer to the custom partition and the custom_logo partition in a differentiated manner; wherein, the customized resource package corresponds one-to-one with the customer's customization requirements; the custom partition is used to store the customer's exclusive customized boot animation file and customized Android application installation package, and the custom_logo partition is used to store the customer's exclusive customized boot logo image; after the Android terminal device is powered on, the BootLoader is triggered to detect the customized boot logo image in the custom_logo partition and load and display it on the screen; a preset animation loading module is called to load the customized boot animation file in the custom partition and execute the boot animation display process; after the Android system completes boot and enters the desktop, it scans the customized Android application installation package in the preset APK storage directory in the custom partition and completes the application installation according to the customer's preset strategy. In this invention, by adding a new customer-customized partition to store customer-differentiated customized resources, multi-customer differentiated customization is realized without modifying the system source code or resource files, avoiding increased R&D and maintenance costs. It also eliminates the need to use flashing tools or scripts to install customized resources for different customers, avoids conflicts with system files, and eliminates the risk of tampering. This overcomes the shortcomings of low efficiency and high maintenance costs in current multi-customer differentiated customization. Attached Figure Description

[0041] Figure 1 This is a schematic diagram of the steps of an Android startup method supporting multi-customer differentiated customization in one embodiment of the present invention;

[0042] Figure 2 This is a structural block diagram of an Android boot device that supports multi-customer differentiated customization in one embodiment of the present invention;

[0043] Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0044] The implementation, functional features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0045] It is particularly important to note that all technical steps, algorithm applications, and parameter settings in the technical solution of this application have clear technical objectives and application value. They do not utilize complex steps and algorithmic formulas to achieve simple functions. To provide detailed explanations of each step and avoid ambiguity, some conventional algorithms are used for illustration. However, this does not mean that the algorithms and technical features listed herein are the only way to implement the technical solution of this application, nor is it intended to limit the scope of protection of this application. This application is not a combination or stacking of the listed algorithms and technical features; its essence is to exemplify the implementation methods of this application to fully explain it. It does not pursue formal complexity by adding meaningless technical steps, nor does it involve the accumulation of technologies divorced from practical needs; it conforms to the conventional logic of technical improvement and design.

[0046] Reference Figure 1 One embodiment of the present invention provides an Android startup method that supports multi-customer differentiated customization, including the following steps:

[0047] Step S1: In the storage partition architecture of the Android system, add two independent customer-customized partitions, namely the custom partition and the custom_logo partition;

[0048] Step S2: During the factory production stage of the Android terminal device, the customized resource package corresponding to the customer is burned into the custom partition and the custom_logo partition in a differentiated manner; wherein, the customized resource package corresponds one-to-one with the customer's customization requirements; the custom partition is used to store the customer's exclusive customized boot animation file and customized Android application installation package, and the custom_logo partition is used to store the customer's exclusive customized boot logo image;

[0049] Step S3: After the Android terminal device is powered on, the BootLoader is triggered to detect the customized boot logo image in the custom_logo partition and load and display it on the screen.

[0050] Step S4: Invoke the preset animation loading module, load the customized boot animation file in the custom partition, and execute the boot animation display process;

[0051] Step S5: After the Android system completes startup and enters the desktop, it scans the customized Android application installation packages in the preset APK storage directory in the custom partition and completes the application installation according to the customer's preset strategy.

[0052] In this embodiment, as described in step S1 above, the aim is to specifically modify the storage architecture of the Android system by adding two independent customer-customized partitions to the existing storage partitions, thus constructing a storage space dedicated to differentiated customization. Both the `custom` partition and the `custom_logo` partition have independent storage address ranges and access permission controls, and are explicitly identified as customer-customized exclusive areas in the system partition table. This partition design physically isolates customer-customized resources from native system resources at the storage level, avoiding interference from customized resources to core system files and providing a structured storage carrier for subsequent differentiated resource management for different customers, ensuring the storage independence and management convenience of customized content.

[0053] As described in step S2 above, a differentiated flashing process is achieved by establishing a one-to-one mapping between customer needs and customized resource packages. In practice, the production system first matches the corresponding customized resource package based on the customer's order information. This resource package contains a customized boot animation file, a customized Android application installation package, and a customized boot logo image that perfectly match the customer's needs. Subsequently, using a dedicated partition flashing tool, the boot logo image is precisely written to the preset path of the custom_logo partition, and the boot animation file and application installation package are written to their respective subdirectories in the custom partition. This targeted flashing method ensures that the customized resources for different customers are strictly limited to their dedicated partitions, achieving efficient differentiated processing in the production process and providing clear path guidance for resource loading during subsequent system startup.

[0054] As described in step S3 above, this is the first customized execution stage in the system startup phase. Through logical modifications to the BootLoader, the customized boot logo is loaded first. When the Android terminal device powers on and starts, after completing basic hardware initialization, the BootLoader first scans the preset path of the `custom_logo` partition to check for a customized boot logo image that conforms to the specified format. If a valid image file is detected, the bootloader will directly call the display driver to load the image and output it to the screen; even if there is no valid file in the partition, the system will automatically fallback to the default logo loading process to ensure the continuity of the boot display. This step, by introducing customized logic at the earliest stage of startup, ensures that the customer's exclusive identifier is presented immediately upon device startup, enhancing the brand display effect.

[0055] As described in step S4 above, following the boot logo display process, after the system enters the Android startup phase, a preset animation loading module is activated to load and execute the customized boot animation. This animation loading module is integrated into the system initialization process. After completing the necessary system environment preparations, it will access the animation storage directory of the custom partition to verify the integrity and format compliance of the customized boot animation file. After confirming the file's validity, it will parse the animation description file, load the frame sequence, and control the display timing according to the Android system boot animation execution specifications to fully present the customer-customized animation effect. If there is no valid animation file in the partition, the module will automatically call the system's default boot animation resources to ensure the continuity of the startup process.

[0056] As described in step S5 above, customized applications are deployed through an automatic scanning and intelligent installation mechanism. After the Android system completes desktop initialization, the system starts a customized application management service. This service traverses the APK storage directory within the custom partition according to a preset path, performing signature verification and compatibility testing on the discovered customized application installation packages. After successful verification, the service automatically completes application deployment according to the customer's pre-configured installation strategy (such as silent installation or user-confirmed installation), and triggers the application's first launch or manual launch by the user as needed. This step achieves seamless integration between customized applications and the system startup process, ensuring that customer-specific applications take effect promptly when the device is available. In this embodiment, by adding a customer-customized partition to store customer-differentiated customized resources, multi-customer differentiated customization is achieved without modifying the system source code or resource files, avoiding increased R&D and maintenance costs. It also eliminates the need to install customized resources for different customers using flashing tools or scripts, avoids conflicts with system files, and eliminates the risk of tampering, overcoming the current shortcomings of low efficiency and high maintenance costs in multi-customer differentiated customization.

[0057] In one embodiment, if the BootLoader does not detect a customized boot logo image, it loads the default Android system boot logo image.

[0058] If the preset animation loading module does not detect the customized boot animation file, the default Android system boot animation file will be loaded.

[0059] In this embodiment, when the BootLoader does not detect a customized boot logo image in the custom_logo partition, it will automatically load the default boot logo image native to the Android system to ensure the continuity of the boot display process. When the preset animation loading module does not find a customized boot animation file in the custom partition, it will load the default boot animation file of the Android system to ensure that the boot animation process is executed normally and to avoid interruption of the boot process due to the lack of customized resources.

[0060] In one embodiment, the method further includes:

[0061] Read the preset customer-specific custom prop parameters in the Android system's build.prop configuration file, parse the values ​​of each parameter, and execute the corresponding system function differentiation process according to the parameter values; at least including hiding the Google Play app icon, disabling Google Play services from starting in the background, and loading customer-specific UI resource files stored in the custom partition.

[0062] In this embodiment, deeper customization of system functions is achieved by parsing customer-specific custom attribute parameters in the system configuration file. Specifically, during startup, the system reads pre-set customer-specific custom prop parameters (such as parameters controlling Google Play display status and specifying UI resource paths) in the Android system's build.prop configuration file. After parsing the specific values ​​of these parameters, the system executes the corresponding system function adjustment process.

[0063] When parsing parameters controlling the display of Google Play, if the parameter indicates hiding, the system hides the Google Play desktop icon through the application management service and restricts its background startup permissions, ensuring that the application is not displayed or running on the client's terminal. When parsing configuration parameters for client-specific UI resources, the system loads the corresponding client-specific UI resource files (such as themes, interface layouts, etc.) stored in the custom partition, replacing the system's default UI elements to achieve customized interface style. This mechanism, through parameterized configuration, enables multi-dimensional functional differentiation without modifying the core system code. It expands the scope of customization while maintaining the stability of the system infrastructure, allowing for the precise implementation of personalized functional requirements from different clients.

[0064] In one embodiment, before completing the application installation according to the customer's preset strategy, the process includes:

[0065] The system performs signature and integrity verification on customized Android application installation packages. Once the verification is successful, the application is installed according to the customer's preset strategy, and the application is automatically launched or waits for the user to launch it manually based on the startup configuration.

[0066] In this embodiment, before executing the customized Android application installation process according to the customer's preset strategy, the application installation package (APK) to be installed in the custom partition is first subjected to dual verification to ensure the legality and integrity of the application. Specifically, the signature verification step extracts the digital signature information built into the installation package and compares it with the legal signature certificate pre-registered by the customer to confirm that the application is an authorized customized version, preventing unauthorized applications from being implanted into the system; the integrity verification calculates the hash value (such as MD5, SHA value) of the installation package and compares it with the baseline hash value recorded during burning to ensure that the application file has not been tampered with, damaged or maliciously modified during storage or transmission.

[0067] Only after both verifications pass will the application installation operation be performed according to the customer's preset installation strategy (such as silent installation without user intervention, installation after prompting the user to confirm via a pop-up window, etc.). After installation, the system further reads the customer's pre-configured startup rules: if the rule is set to automatic startup, the application's first startup process is triggered, making it immediately available; if the rule is set to manual startup, the application icon is added to the system desktop, waiting for the user to actively click to launch it.

[0068] The above process ensures the security of customized applications through a rigorous verification mechanism, while flexible installation and startup strategies meet the personalized needs of different customers for application deployment methods, ensuring that customized applications can be integrated into the system securely and compliantly, and can also be adapted to the actual use scenarios of customers.

[0069] In one embodiment, two independent, custom-designed partitions are added to the storage partition architecture of the Android system, including:

[0070] Using the Android system partitioning tool, two custom partitions with configurable capacity, custom_logo and custom_logo, are created in the eMMC / NAND Flash storage medium of the Android terminal device. Mount information for these two custom partitions is then added to the fstab configuration file of the Android system.

[0071] In this embodiment, specifically, a partitioning tool supported by the Android system (such as parted) is first used to divide the terminal device's eMMC or NAND Flash storage medium into two independent storage areas: a "custom" partition and a "custom_logo" partition. The capacity of these two partitions is not fixed and can be flexibly configured according to the size requirements of different customers' customized resources to adapt to different scales of customized content storage.

[0072] Subsequently, to ensure that the Android system can correctly recognize and access these two newly added partitions during startup, corresponding mount information needs to be added to the system's fstab configuration file. This information includes the partition's device identifier (e.g., / dev / block / mmcblk0pX), mount point (i.e., the path to access the partition in the system), file system format, and mount parameters (e.g., read / write permissions, mount timing, etc.). By configuring this in the fstab file, the system will automatically mount these two partitions according to preset rules during startup, making them part of the Android system file architecture and providing a basic storage medium for the subsequent burning, storage, and loading of customized resources.

[0073] The above process achieves physical isolation between customized partitions and existing system partitions, and ensures the accessibility of partitions through system configuration, laying the underlying storage foundation for independent management of multi-customer differentiated customized resources.

[0074] In one embodiment, when an Android terminal device needs to change to meet customer customization requirements, the original files in the custom partition and the custom_logo partition are erased using system recovery mode or a factory flashing tool, and the new customized resource package for the customer is re-flashed.

[0075] In this embodiment, when the terminal device needs to switch from the original customer customization requirements to new customer requirements (or update the customized content for the same customer), the operation can be performed through two technical paths: The first is to enter the system recovery mode. This mode serves as an independent recovery environment for the Android system, which can bypass the limitations of normal system operation and directly operate on the storage partition. In this mode, selecting the erase command for the custom partition and the custom_logo partition can clear the original boot animation, application installation package, boot logo and other customized resources in the partition; The second is to use a factory flashing tool (such as fastboot, dedicated partition flashing software) to send erase commands to the two customized partitions through a dedicated connection channel between the device and the computer (such as USB debugging mode) to clear the original resources.

[0076] After erasing the existing files, the new customer's customized resource package (including a new boot logo, boot animation, customized applications, etc.) is then flashed to the corresponding custom partition and custom_logo partition using the same recovery mode or factory flashing tool. The entire process only operates on two independent customized partitions, without modifying the core partitions of the Android system (such as system and boot partitions) and basic code. This allows for rapid response to changes in customer requirements, avoids stability risks caused by modifying the core system, and significantly reduces the operational complexity and time cost of requirement iteration.

[0077] In one embodiment, the method further includes:

[0078] Collect data throughout the entire lifecycle of Android terminal devices; obtain customized trend data from clients in the same industry;

[0079] Analyze the entire lifecycle data and customization trend data to predict customers' potential customization needs for the future preset cycle;

[0080] Based on potential customization needs, pre-adapted resource operations are automatically performed during idle periods on Android terminal devices; when customers raise actual customization needs, pre-adapted resources are directly invoked to complete rapid deployment.

[0081] In this embodiment, the entire lifecycle data of the Android terminal device is continuously collected, including device startup logs, customized resource usage records, and hardware performance degradation parameters (such as changes in storage read / write speed and memory usage trends). At the same time, the system accesses an industry database to obtain customization trend information from customers in the same industry, including common characteristics such as mainstream customized function types, resource format upgrade directions, and requirement iteration cycles.

[0082] Based on the above data, the system uses pre-set analytical models (such as trend prediction algorithms) to conduct multi-dimensional analysis and infer potential customization needs that customers may have in the future within a preset period (such as 3-6 months). For example, based on a customer's historical pattern of updating the boot animation once a quarter, combined with the industry trend of 4K animation popularization, it predicts that the customer may need to support a higher resolution boot animation in the next quarter; based on data analysis of the gradual shortage of device memory, it is predicted that the customer may need a lightweight version of the customized application.

[0083] Based on these predictions, pre-adaptation resource operations will be automatically performed when the device is idle (such as during overnight charging or long periods of inactivity): if the prediction requires support for a new animation format, the corresponding format conversion tools and adaptation templates will be stored in the custom partition in advance; if the prediction indicates the need for lightweight applications, the adaptation patch package will be downloaded to a dedicated directory in advance. When customers subsequently raise actual customization requirements that match the predictions, the system does not need to redevelop or adapt from scratch, and can directly call the pre-stored adaptation resources, significantly shortening the customization deployment cycle and improving response efficiency.

[0084] The above mechanism upgrades the traditional demand-based response model to a proactive service model that anticipates and prepares in advance, reducing the time cost of customized iterations and enhancing the ability to quickly adapt to changes in customer needs.

[0085] In one embodiment, the full lifecycle data includes historical startup logs, customer-customized resource iteration records, and hardware wear parameters such as storage read / write counts and screen brightness decay values.

[0086] Pre-adaptation of resources includes: if it is predicted that 4K animation support is required, then a 4K animation format conversion tool and adaptation template are generated in advance in the custom partition; if it is predicted that lightweight application is required, then the corresponding customer's application lightweight patch package is downloaded and stored in a subdirectory of the custom partition.

[0087] In this embodiment, during the full lifecycle data acquisition phase, the system focuses on key data throughout the entire process from device production to use, constructing a multi-dimensional data foundation to support accurate predictions. Historical startup logs record the customized resource loading status (such as logo loading time, whether animations execute correctly), system response efficiency, and other information each time the device starts, reflecting the compatibility between customized resources and the device startup process. Customer-customized resource iteration records analyze past customer needs regarding the frequency and type of updates to the boot logo, animations, and applications, providing a basis for determining the direction of requirement iterations. Hardware wear parameters, such as storage read / write cycles and screen brightness decay, reflect the changing trends in device hardware performance—for example, excessive storage read / write cycles may lead to a decrease in subsequent resource loading speed, and screen brightness decay may require adjustments to the logo display brightness. This data helps predict hardware compatibility requirements and avoids the impact of hardware aging on customization results.

[0088] In the pre-adaptation resource operation phase, targeted resource preparation strategies are formulated for different types of potential customization needs to ensure that resources can be quickly called upon when the needs are implemented. For example, if data analysis predicts that a customer will need to support 4K resolution boot animations in the future, the system will automatically generate a 4K animation format conversion tool and an adaptation template in the custom partition during device idle periods. The conversion tool can quickly convert ordinary resolution animation materials provided by the customer into 4K format, while the adaptation template includes the parameter configuration of 4K animations (such as frame rate and compression ratio) and compatibility rules with different screen resolutions, avoiding repeated development during subsequent adaptation. If it is predicted that a customer needs a lightweight customized application, the system will download the corresponding lightweight application patch package (such as patches to remove redundant functional modules and compress image resources) from the preset patch library based on the functional modules and resource usage of the customer's existing customized application, and store it in a dedicated subdirectory of the custom partition. When the customer makes a request, they only need to call the patch package to modify the existing application without having to redevelop a lightweight version, which greatly shortens the customization cycle.

[0089] In one embodiment, the method further includes:

[0090] When the Android system boots up for the first time, it generates a unique fingerprint for the Android terminal device, binds the unique fingerprint to the customer's digital certificate, stores it in the custom partition directory, and uploads it to the cloud security database.

[0091] Establish a baseline for the startup behavior of Android terminal devices, including CPU usage curves, memory loading rates, and frequency of access to custom partition files during normal startup.

[0092] During each startup process, the current startup behavior is compared with the startup behavior baseline in real time. If an anomaly is detected, a security protection mechanism is immediately triggered. The security protection mechanism includes pausing the loading of customized resources, locking access permissions to the custom partition, and prompting the administrator to perform device unique fingerprint verification via a local pop-up window on the Android terminal device.

[0093] In this embodiment, when an Android terminal device is first booted, the system triggers a dedicated device identity authentication initialization process to generate a unique fingerprint for the device. Specifically, it extracts unique identifiers at the device hardware level (such as CPU serial number, motherboard MAC address, and eMMC storage chip ID) and system-level feature information (such as Android system UUID and first boot timestamp). The above information is then hashed using an encryption algorithm to generate an immutable and unique string, i.e., the device's unique fingerprint. This fingerprint can accurately identify a single device, avoiding identity confusion.

[0094] Subsequently, the generated unique device fingerprint is bound to the customer's digital certificate (a digital credential based on an asymmetric encryption algorithm, provided by the customer or generated exclusively for the customer by the system), forming a unique correspondence between the device and the customer. After binding, the associated data is encrypted and stored in a preset secure directory in the custom partition (e.g., " / security / device_cert"), and simultaneously uploaded to a cloud security database via an encrypted transmission channel (e.g., HTTPS protocol). Local storage ensures that device authentication can still be performed offline, while cloud storage facilitates unified management of device identity and customer attribution by the factory or operations and maintenance department, preventing unauthorized tampering with customer attribution information.

[0095] To enable anomaly monitoring during the device startup process, a startup behavior baseline construction process is initiated after the device's initial startup and completion of normal customized configuration. This process uses a background monitoring module to collect key operational metrics during the normal device startup process in real time and standardize them into baseline data. Specifically, this includes: CPU usage curves, which record the CPU usage changes throughout the entire process from device power-on to desktop loading (e.g., 20%-30% CPU usage during the BootLoader phase, 40%-60% during system initialization, and dropping back to 10%-20% after desktop startup); memory loading rate, which tracks the growth rate and peak value of memory usage at each startup stage (e.g., memory usage increases at a rate of 50MB / s during boot animation loading, with a peak value not exceeding 300MB); and custom partition file access frequency, which records the number of times and time intervals the system reads each customized resource file in the custom partition during startup (e.g., the boot logo file is accessed only once during the BootLoader phase, while the boot animation file is accessed 10-15 times consecutively during system startup).

[0096] After the system collects the above-mentioned indicator data, it performs noise reduction and normalization processing to generate a startup behavior baseline specific to the device, which is stored in the system security partition (such as " / system / etc / baseline") as the benchmark for judging whether there are any abnormalities during each subsequent startup.

[0097] During each subsequent device startup, the background monitoring module collects real-time operational metrics such as CPU usage curves, memory loading rates, and custom partition file access frequency, and performs step-by-step, multi-dimensional comparative analysis with pre-stored startup behavior baselines. If a deviation exceeding a preset threshold is detected between the current metrics and the baseline (e.g., CPU usage suddenly spikes to 90% during system initialization and lasts for more than 10 seconds, far exceeding the baseline's 60% limit; or application installation package files in the custom partition are accessed abnormally more than 20 times, deviating from the baseline's normal range of 5-8 times), then an anomaly is determined to exist in the startup process (possibly due to unauthorized programs tampering with customized resources, malicious injection of illegal files, etc.).

[0098] Upon detecting an anomaly, the system immediately triggers a security protection mechanism: First, it suspends the loading process of the current customized resources (e.g., stopping the boot animation playback or interrupting application installation) to prevent the abnormal resources from continuing to execute; second, it locks access permissions to the custom partition, prohibiting any process (including system processes) from reading or writing files within the partition to prevent further tampering with customized resources; simultaneously, an administrator verification pop-up appears on the device screen, requiring the administrator to enter the device's unique fingerprint (or authenticate via the bound customer digital certificate). Only after the administrator completes authentication and confirms that the anomaly is a false alarm or the risk has been eliminated will the system unlock the partition and resume the customized resource loading process; if verification fails or times out, the system will maintain the protected state and push anomaly alert information to the cloud security platform for remote investigation and handling, comprehensively ensuring the security and integrity of customized resources during device startup.

[0099] In one embodiment, when a customer changes their customization requirements and needs to re-flash resources, the administrator is required to provide both the new customer's digital certificate and the device's unique fingerprint in the cloud security database for dual verification. Only after the dual verification is successful can the original files in the custom partition and the custom_logo partition be erased.

[0100] In this embodiment, when a customer requests a change in customization (e.g., switching from customer A's customization plan to customer B's customization plan), requiring the erasure and re-burning of existing resources in the custom partition and custom_logo partition, a dual identity and permission verification process is first triggered: The first step requires the administrator to provide the digital certificate corresponding to the new customer (this certificate is an encrypted credential exclusive to the new customer, pre-registered by the system in the cloud security database, possessing uniqueness and unforgeability). The system verifies the validity of the certificate through its built-in certificate parsing module (including whether the certificate signature is compliant, whether the validity period is within the range, and whether it matches the new customer's identity); The second step requires the administrator to provide the unique fingerprint of the device registered in the cloud security database (i.e., the encrypted string generated and uploaded when the device is first started, bound to hardware and system characteristics). The fingerprint entered by the administrator is compared with the fingerprint information stored in the cloud to confirm that the device currently being operated on is a registered legitimate device.

[0101] Only when the new customer's digital certificate is verified (confirming the legitimacy of the new customized request) and the device's unique fingerprint is matched (confirming the device is compliant) will the erase permissions for the custom partition and custom_logo partition be unlocked, allowing the administrator to clear the original customized resources through recovery mode or factory flashing tools. If any verification step fails (such as an invalid certificate or mismatched fingerprint), the system will immediately block the erase operation, generate an operation log and upload it to the cloud security platform, while simultaneously displaying a pop-up message locally indicating verification failure and prohibiting resource erasure. This fundamentally avoids customized resource chaos or device security risks caused by illegal operations (such as using forged certificates or operating on non-registered devices), ensuring the security and compliance of the customer's customized request change process.

[0102] In one embodiment, generating a unique fingerprint for an Android terminal device includes:

[0103] The data acquisition device's hardware dynamic characteristics include the microarchitecture instruction sequence characteristics of the CPU during runtime and the brightness decay curve parameters of the display backlight module.

[0104] Extract nonlinear characteristic parameters during system startup, including the loading time fluctuation of the BootLoader, the process scheduling delay sequence during the Linux kernel initialization phase, and the frame interval difference when the Android Framework layer first draws the desktop.

[0105] The device hardware dynamic features and nonlinear feature parameters are used as network nodes. The node connection weights are generated by calculating the mutual information entropy between features, forming a unique feature association topology. The adjacency matrix of the feature association topology is used as the first feature encoding.

[0106] Initial conditions are constructed based on the geographic coordinates of the device's first startup. The Lorenz chaotic system is used to iteratively map the first feature encoding to generate a chaotic encrypted sequence.

[0107] The chaotic encryption sequence is decomposed into hardware feature subsequence, system feature subsequence and spatiotemporal feature subsequence, and a three-dimensional fingerprint matrix is ​​constructed. Finally, the unique fingerprint of the device is output by the feature value operation of the three-dimensional fingerprint matrix. When the physical state of the device or the startup environment changes slightly, the unique fingerprint of the device will show traceable feature drift.

[0108] In this embodiment, when collecting CPU microarchitecture instruction sequence characteristics, a lightweight test program is run during the device's first boot, allowing the CPU to execute basic instructions such as addition and shifting. Simultaneously, the number of pipeline pauses and cache hit / miss intervals during these instruction executions are recorded in real time. Even for CPUs of the same model, these data will differ due to variations in manufacturing processes. When collecting backlight module brightness decay curve parameters, the initial backlight brightness data stored at the device's factory is retrieved first. Then, during the first boot, a light sensor detects the actual brightness at different brightness levels, calculating the decay difference between the actual and initial brightness to form a brightness decay curve. Due to differences in the physical characteristics of LED beads, the decay curves of devices from the same batch will also differ. These two types of features together constitute a unique identifier at the hardware level.

[0109] The non-linear characteristics during system startup, influenced by hardware and software interactions, are inherently unique. This step involves extracting these characteristics. When extracting the BootLoader loading time fluctuation, the device is booted three times consecutively. The total time from BootLoader startup to kernel loading is recorded each time, and the standard deviation of these three times is calculated. This fluctuation reflects the efficiency of the interaction between the BootLoader and hardware initialization, and varies from device to device due to motherboard circuit stability. When extracting the Linux kernel initialization process scheduling delay sequence, during the kernel startup phase, the kernel log records the process creation and scheduling times. The time interval between adjacent process scheduling is calculated, forming a sequence containing 5 to 8 interval values. The sequence value distribution varies significantly across different devices due to differences in kernel driver loading order and hardware response speed. When extracting the Android Framework desktop rendering frame interval difference, the SurfaceFlinger service records the rendering time of each frame when the system first renders the desktop. The interval between two adjacent frames is calculated, and the difference between the maximum and minimum interval values ​​is found. This difference is affected by GPU rendering capabilities and memory read / write speeds, and is a unique startup identifier of the Framework layer.

[0110] Next, the dispersed hardware and system characteristics are transformed into a structured, unique code by constructing a network topology. First, the two types of dynamic hardware characteristics and three types of nonlinear system characteristics collected earlier are defined as five network nodes, each with its own characteristic value; for example, the CPU node represents the number of pipeline pauses, and the display node represents the slope of the decay curve. Then, the connection weight between any two nodes is calculated, using mutual information entropy to measure the strength of the association between nodes. For example, a strong correlation between CPU instruction sequence characteristics and kernel scheduling latency sequences results in a high mutual information entropy value, leading to a large connection weight for the corresponding node. Conversely, a weak correlation between the display brightness decay curve and BootLoader loading fluctuations results in a small weight. Then, based on the connection relationships and weights of the five nodes, a 5×5 adjacency matrix is ​​constructed. The elements in the matrix represent the weight values ​​between nodes, with zeros filled in for unconnected nodes. Finally, this adjacency matrix is ​​converted into a binary sequence in row-major order. This sequence is the first feature code; the matrix is ​​different for each device, and the code is unique.

[0111] In chaotic systems, even minute differences in initial conditions can lead to drastically different results. This characteristic can be used to generate highly secure encrypted sequences. First, the device's geographical coordinates are acquired upon initial startup. For example, base station positioning is used when there is network coverage, and the device's built-in IMU inertial sensor records relative position changes when there is no network. These coordinate values ​​are then converted to decimal numbers and used as the initial input data for the Lorenz chaotic system. Next, the binary sequence of the first feature encoding is divided into groups of 8 bits, and each group is converted to a decimal number, serving as the iteration step size for the chaotic system. For example, if a group of binary bits is 10101010, which is 170 decimal, the step size is set to 170. Then, the initial input data and iteration step size are substituted into the chaotic system for 100 to 200 iterations, with each iteration outputting a set of data. Finally, all iteration results are concatenated sequentially to form a chaotic encrypted sequence. Because each device has a different geographical location, even if the first feature encoding is the same, the encrypted sequence will be completely different.

[0112] Then, by constructing a matrix and calculating eigenvalues, the generated fingerprint is made stable, difficult to copy, and allows for traceable feature drift. First, the chaotic encryption sequence is split into three sub-sequences based on feature type: the hardware feature sub-sequence corresponds to the iteration results of CPU and display features; the system feature sub-sequence corresponds to the iteration results of BootLoader, kernel, and Framework features; and the spatiotemporal feature sub-sequence corresponds to the iteration results of initial geographical location conditions. Then, the values ​​of these three sub-sequences are used as the x, y, and z axis data of a three-dimensional matrix to construct a 3-row, N-column three-dimensional fingerprint matrix, where N is the length of the sub-sequence, typically set to around 50. Next, singular value decomposition is performed on this three-dimensional fingerprint matrix, extracting the first 8 largest singular values. Singular values ​​reflect the core features of the matrix and are relatively stable. These 8 singular values ​​are then converted to hexadecimal numbers and concatenated to form a 32-bit unique device fingerprint. When the physical state of a device changes, such as CPU aging, or the startup environment changes, such as a change in geographical location, the hardware or system characteristics will be fine-tuned, and the singular values ​​of the matrix will also fluctuate slightly, which is called feature drift. However, because the matrix retains the correspondence between feature types, it can trace back the cause of the drift, ensuring that the fingerprint can be associated with the original device and preventing it from being copied.

[0113] In one embodiment, generating a unique fingerprint for an Android terminal device includes:

[0114] Obtain the CPU serial number, motherboard MAC address, and eMMC storage chip ID of the Android terminal device, and extract the core identifier segment from the CPU serial number;

[0115] The CPU serial number, motherboard MAC address, and eMMC storage chip ID are converted into binary to obtain the corresponding binary sequences.

[0116] The numbers in each binary sequence are added bit by bit to the binary tree to form a hardware feature binary tree;

[0117] The key features at the start of the acquisition system are used as control point parameters for the Bézier curve to generate a unique system feature Bézier curve.

[0118] Perform a preorder traversal on the hardware feature binary tree, and combine the values ​​of the nodes in the traversal process into a first combination binary sequence; discretize the system feature Bézier curve, select a number of points evenly on the curve, and convert the coordinate values ​​of each selected point into a second combination binary sequence.

[0119] Bit-level cross-mixing is performed on the first and second combined binary sequences to obtain a mixed feature sequence;

[0120] A dynamic adjustment factor is generated based on the depth of the hardware feature binary tree and the curvature of the system feature Bézier curve. The constants and variables in each round of the compression function of the hash algorithm are dynamically modified by the dynamic adjustment factor, and the mixed feature sequence is hashed to generate a unique fingerprint of the device.

[0121] In this embodiment, the three core hardware information of the Android terminal device are first obtained: CPU serial number, motherboard MAC address, and eMMC storage chip ID. These are unique hardware identifiers fixed at the factory and will not change with use. Next, the CPU serial number is further processed. For example, the middle 8 bytes are extracted from the complete CPU serial number as a core identifier segment, eliminating any common prefixes / suffixes at the beginning and end, focusing on the key parts that reflect the individual differences of the CPU, ensuring the uniqueness of subsequent features. The motherboard MAC address and eMMC storage chip ID are retained in their entirety to prepare for subsequent binary conversion.

[0122] Hardware identifiers are transformed into a visual binary tree structure to enhance the non-replicability of features. First, the extracted CPU serial number (including the core identifier segment), motherboard MAC address, and eMMC memory chip ID are converted into binary sequences. Then, a hardware feature binary tree is constructed according to a bit-by-bit addition rule: the highest bit of the first hardware binary sequence is used as the root node of the binary tree; if the bit is 0, the next bit becomes the left child node; if it is 1, it becomes the right child node. Subsequent hardware binary sequences are filled layer by layer from the root node according to the same rule, continuing downwards when an existing child node is encountered, ultimately forming a structurally unique hardware feature binary tree. Since the hardware information of each device is different, the node distribution of the binary tree will also be completely different.

[0123] Next, the system startup characteristics are visualized using Bézier curves to uncover system-level uniqueness. First, key features during device system startup are collected, such as the ASCII values ​​corresponding to the last 8 characters of the Android system Build ID, kernel loading time, and the number of system services. These key features are then used as control point parameters for the Bézier curve: for example, kernel loading time is used as the X-axis, the sum of the ASCII values ​​of the Build IDs as the Y-axis, and the number of system services determines the order of the Bézier curve (5 services result in a 5-order Bézier curve). By adjusting the positions of these control points, a system-specific Bézier curve is generated. Different devices exhibit different startup characteristics, resulting in significant differences in the curvature and inflection point positions of the curve, thus becoming a unique identifier at the system level.

[0124] Then, the visualized hardware binary tree and system Bézier curve are converted into a computable binary sequence. For the hardware feature binary tree, a preorder traversal is used, and the values ​​of each node during the traversal are sequentially concatenated to form a complete first-combination binary sequence, preserving the structural features of the binary tree. For the system feature Bézier curve, discretization is performed, and 16 points are evenly selected on the curve (the number can be adjusted according to accuracy requirements). For example, the curve can be divided into 15 segments from the start to the end, and the endpoints of each segment are the selected points. Then, the X and Y coordinate values ​​of each point (e.g., X=120ms, Y=350) are converted into binary numbers, and the binary coordinate values ​​of all points are sequentially concatenated to form a second-combination binary sequence, converting the morphological features of the curve into a computable numerical sequence.

[0125] Furthermore, through cross-mixing, hardware and system characteristics are deeply bound together to form a more unique hybrid sequence. The specific operation is to process the first and second binary sequences according to the bit-by-bit alternation rule: first take the first bit of the first binary sequence, then take the first bit of the second binary sequence, then take the second bit of the first binary sequence, the second bit of the second binary sequence, and so on, until all bits of the two sequences have been crossed, finally obtaining a hybrid feature sequence that integrates hardware and system information.

[0126] Finally, the security and uniqueness of the fingerprint are ensured by optimizing the hash algorithm. First, two key parameters are calculated: the depth of the hardware feature binary tree (the maximum number of levels from the root node to the bottom leaf node; for example, if the binary tree has 8 levels, the depth is 8), and the curvature of the system feature Bézier curve (calculated by the average curvature value based on the degree of curvature of different segments of the curve). These two parameters are multiplied or weighted proportionally to generate a dynamic adjustment factor. Then, this adjustment factor is used to modify each round of the compression function in a traditional hash algorithm (such as SHA-256): for example, adjusting fixed constants in the compression function (e.g., multiplying the originally fixed Kt value by the adjustment factor), or modifying variables involved in the calculation (e.g., performing bit-level left / right shifts on variables, with the number of shift bits determined by the adjustment factor), breaking the fixed operational logic of the traditional hash algorithm. Finally, the mixed feature sequence is input into the modified hash algorithm for calculation, and the output hash value is the device's unique fingerprint. Because the dynamic adjustment factor is strongly bound to the binary tree depth and curve curvature of each device, even if the mixed sequences are similar, the final generated fingerprint will be completely different, ensuring the uniqueness and anti-copying properties of the device identifier.

[0127] In one embodiment, generating a unique fingerprint for an Android terminal device includes:

[0128] The CPU serial number, motherboard MAC address, and eMMC storage chip ID are obtained as three core feature nodes, and each node is assigned a binary value attribute.

[0129] A triangular graph structure is formed by three core nodes. The edge weights between the CPU and motherboard nodes are set according to the reciprocal of the Hamming distance between their binary values. The edge weights between the motherboard and EMMC nodes are set according to the factory-fixed bus interaction frequency. The edge weights between the CPU and EMMC nodes are set according to the XOR sum of their binary values. The adjacency matrix of the graph structure is extracted as the core hardware feature data.

[0130] Collect Android system factory characteristics and generate heatmaps based on these characteristics;

[0131] The first algorithm parameter of the hash algorithm is perturbed based on the core data of hardware features, and the second algorithm parameter of the hash algorithm is perturbed based on the heat map to obtain the perturbed hash algorithm.

[0132] The CPU serial number, motherboard MAC address, and EMMC storage chip ID are calculated using a perturbation hash algorithm, and a unique fingerprint of the device is generated based on the calculation results.

[0133] In this embodiment, three immutable hardware pieces of information are first obtained from the Android terminal device: CPU serial number, motherboard MAC address, and eMMC storage chip ID. These three are unique identifiers fixed at the time of device manufacture and will not change due to use or system updates. They are directly defined as three core feature nodes. Then, the hardware information corresponding to each node is converted into binary, so that the three core nodes have unique binary value attributes.

[0134] Furthermore, by constructing a graphical structure, the relationships between hardware nodes are quantified to form core hardware feature data. A triangular graph structure is constructed with the CPU node, motherboard node, and eMMC node as the three vertices, focusing on the unique relationships between nodes through edge weights. The specific weight setting rules are as follows: the edge weight between the CPU and motherboard nodes is calculated as the reciprocal of the Hamming distance between their binary values ​​(i.e., the number of different corresponding bits in the two binary sequences); the edge weight between the motherboard and eMMC nodes directly uses the bus interaction frequency fixed at the factory (e.g., if the motherboard and eMMC communicate via the SDIO bus, and the average interaction frequency recorded in factory tests is 50 times / second, the weight is set to 50), this parameter reflects the physical interaction characteristics of the hardware module; the edge weight between the CPU and eMMC nodes is calculated by performing an XOR operation on their binary values ​​(corresponding bits are the same, 0 is obtained; different bits are 1), and then summing the number of 1s in the XOR result as the weight. Finally, based on the three vertices of the triangular graph and the edge weights, a 3×3 adjacency matrix is ​​constructed. This adjacency matrix completely records the relationships between hardware nodes, becoming the core hardware feature data.

[0135] Next, focusing on the inherent factory characteristics at the system level, we transform them into a visual and quantifiable feature carrier through heatmaps. First, we collect the factory-fixed characteristics of the Android system. These characteristics do not change with user usage, such as the last 8 characters of the system Build ID, the factory-preset system timezone offset, the number of pre-installed system applications, and key segments of the kernel version number. Then, we determine the coordinate system and pixel value rules for the heatmap: using the number of system applications as the X-axis and the timezone offset segment as the Y-axis, we add the ASCII code value of the last 8 characters of the Build ID to the kernel version segment value, and normalize the result to 0-255 (grayscale range), using it as the grayscale value for the corresponding pixel in the heatmap. We fill all pixels according to this rule, generating a system feature heatmap. Since the factory characteristics differ for different devices, the grayscale distribution of the heatmap will also be unique.

[0136] By perturbing the hash algorithm parameters using both hardware and system characteristics, the fixed logic of traditional algorithms is broken, forming a unique encryption rule. The first algorithm parameter is perturbed based on the core hardware feature data (adjacency matrix): the nine weight values ​​of the 3×3 adjacency matrix are converted into nine decimal numbers in row-major order. The first eight values ​​are then added to the default initial hash value of the SHA-256 algorithm, completing the hardware feature binding of the first algorithm parameter. Next, the second algorithm parameter (compression function constant) is perturbed based on the heatmap: the grayscale values ​​of all pixels in the heatmap are summed to obtain the total grayscale value. This total grayscale value is divided by 64 (the number of compression function constants) to obtain the average perturbation value. This average perturbation value is then multiplied by each compression function constant, integrating the system features into the compression function constant. After these two parameter perturbations, the originally fixed SHA-256 algorithm becomes a perturbed hash algorithm strongly bound to the current device's hardware and system characteristics, allowing for different perturbation rules for each device.

[0137] Finally, a unique device fingerprint with high uniqueness and resistance to duplication is generated through a proprietary perturbation hash algorithm. First, the original CPU serial number, motherboard MAC address, and eMMC memory chip ID are concatenated into a complete string, which serves as the input data for the perturbation hash algorithm. Because the initial hash value and compression function constant of the perturbation hash algorithm are perturbed by device-specific characteristics, the calculation process differs from traditional SHA-256. The algorithm outputs a 256-bit hash value, which can then be used as the device's unique fingerprint. Since hardware features (adjacency matrix) and system features (heatmap) are deeply involved in perturbing the algorithm parameters during the generation process, and the input data is the device's immutable hardware identifier, even if two devices have the same hardware model, the final generated fingerprints will be completely different due to minor hardware differences (such as different MAC addresses) and differences in system factory characteristics (such as different Build IDs). This ensures the uniqueness of the device identifier and resists attacks that forge fingerprints by copying hardware parameters.

[0138] In the above embodiments, this application incorporates some existing algorithms and technical features for explanation and description to make the specification more detailed, clear, and complete, thus complying with the provisions of the Patent Law. However, this is not achieved by using a series of complex steps and algorithmic formulas, nor by complicating the technical solution, nor by combining or stacking conventional or simple features. The existing algorithms and technical features listed are for the purpose of disclosing the specific implementation methods of each step of this application (not to limit this application) and to avoid situations where this application cannot be implemented.

[0139] Reference Figure 2 In another embodiment of the present invention, an Android boot device supporting multi-customer differentiated customization is also provided, comprising:

[0140] A new module has been added to add two independent customer-customized partitions in the Android system's storage partition architecture: the custom partition and the custom_logo partition.

[0141] The burning module is used to burn customized resource packages corresponding to customers into the custom partition and the custom_logo partition during the factory production stage of Android terminal devices. The customized resource packages correspond one-to-one with the customer's customization requirements. The custom partition is used to store the customer's customized boot animation files and customized Android application installation packages, and the custom_logo partition is used to store the customer's customized boot logo image.

[0142] The first loading module is used to trigger the BootLoader program to detect the customized boot logo image in the custom_logo partition and load and display it on the screen after the Android terminal device is powered on.

[0143] The second loading module is used to call the preset animation loading module, load the customized boot animation file in the custom partition, and execute the boot animation display process;

[0144] The installation module is used to scan the customized Android application installation packages in the preset APK storage directory in the custom partition after the Android system has finished booting and entered the desktop, and complete the application installation according to the customer's preset strategy.

[0145] In this embodiment, the specific implementation of each module in the above device embodiment is described in the above method embodiment, and will not be repeated here.

[0146] Reference Figure 3 This invention also provides a computer device, which can be a server, and its internal structure can be as follows: Figure 3 As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0147] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0148] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0149] In summary, the Android startup method supporting multi-customer differentiated customization provided in this embodiment of the invention includes: adding two independent customer-customized partitions in the storage partition architecture of the Android system, namely a custom partition and a custom_logo partition; during the factory production stage of the Android terminal device, the customized resource package corresponding to the customer is differentially burned to the custom partition and the custom_logo partition; wherein, the customized resource package corresponds one-to-one with the customer's customization requirements; the custom partition is used to store the customer's exclusive customized boot animation file and customized Android application installation package, and the custom_logo partition is used to store the customer's exclusive customized boot logo image; after the Android terminal device is powered on, the BootLoader is triggered to detect the customized boot logo image in the custom_logo partition and load and display it on the screen; a preset animation loading module is called to load the customized boot animation file in the custom partition and execute the boot animation display process; after the Android system completes startup and enters the desktop, the customized Android application installation package in the preset APK storage directory in the custom partition is scanned, and the application installation is completed according to the customer's preset strategy. In this invention, by adding a new customer-customized partition to store customer-differentiated customized resources, multi-customer differentiated customization is realized without modifying the system source code or resource files, avoiding increased R&D and maintenance costs. It also eliminates the need to use flashing tools or scripts to install customized resources for different customers, avoids conflicts with system files, and eliminates the risk of tampering. This overcomes the shortcomings of low efficiency and high maintenance costs in current multi-customer differentiated customization.

[0150] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0151] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0152] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An Android starting method supporting multi-client differentiated customization, characterized in that, Includes the following steps: In the storage partitioning architecture of the Android system, two new independent customer-customized partitions have been added, namely the custom partition and the custom_logo partition. During the factory production stage of Android terminal devices, the customized resource packages corresponding to the customer are burned into the custom partition and the custom_logo partition in a differentiated manner; wherein, the customized resource packages correspond one-to-one with the customer's customization requirements; the custom partition is used to store the customer's exclusive customized boot animation files and customized Android application installation packages, and the custom_logo partition is used to store the customer's exclusive customized boot logo image; After the Android terminal device is powered on, the BootLoader is triggered to detect the customized boot logo image in the custom_logo partition and load and display it on the screen. The preset animation loading module is invoked to load the customized boot animation file in the custom partition and execute the boot animation display process; After the Android system completes startup and enters the desktop, it scans the customized Android application installation packages in the preset APK storage directory in the custom partition and completes the application installation according to the customer's preset strategy. Collect full lifecycle data of Android terminal devices; obtain customization trend data from customers in the same industry; analyze the full lifecycle data and customization trend data to predict potential customization needs of customers in the future preset cycle; based on potential customization needs, automatically perform pre-adapted resource operations during the idle period of Android terminal devices; when customers put forward actual customization needs, directly call the pre-adapted resources to complete rapid deployment.

2. The Android booting method supporting multi-client differentiated customization according to claim 1, characterized in that, If the BootLoader does not detect a customized boot logo image, it will load the default Android system boot logo image. If the preset animation loading module does not detect the customized boot animation file, the default Android system boot animation file will be loaded.

3. The Android booting method supporting multi-client differentiated customization according to claim 1, characterized in that, The method further includes: Read the preset customer-specific custom prop parameters in the Android system's build.prop configuration file, parse the values ​​of each parameter, and execute the corresponding system function differentiation process according to the parameter values; at least including hiding the Google Play app icon, disabling Google Play services from starting in the background, and loading customer-specific UI resource files stored in the custom partition.

4. The Android startup method supporting multi-customer differentiated customization according to claim 1, characterized in that, Before completing the application installation according to the customer's preset strategy, the following is included: The system performs signature and integrity verification on customized Android application installation packages. Once the verification is successful, the application is installed according to the customer's preset strategy, and the application is automatically launched or waits for the user to launch it manually based on the startup configuration.

5. The Android booting method supporting multi-client differentiated customization according to claim 1, characterized in that, In the Android system's storage partition architecture, two new independent customer-customized partitions have been added, including: Using the Android system partitioning tool, two custom partitions with configurable capacity, custom_logo and custom_logo, are created in the eMMC / NAND Flash storage medium of the Android terminal device. Mount information for these two custom partitions is then added to the fstab configuration file of the Android system.

6. The Android booting method of supporting multi-client differentiated customization according to claim 1, characterized in that, When an Android terminal device needs to be customized according to customer requirements, the original files in the custom partition and custom_logo partition are erased through system recovery mode or factory flashing tool, and the new customized resource package for the customer is re-flashed.

7. The Android booting method of supporting multi-client differentiated customization according to claim 1, characterized in that, The full lifecycle data includes historical startup logs, customer-customized resource iteration records, and hardware wear parameters, including storage read / write counts and screen brightness decay values. Pre-adaptation of resources includes: if it is predicted that 4K animation support is required, then a 4K animation format conversion tool and adaptation template are generated in advance in the custom partition; if it is predicted that lightweight application is required, then the corresponding customer's application lightweight patch package is downloaded and stored in a subdirectory of the custom partition.

8. The Android booting method of supporting multi-client differentiated customization according to claim 1, characterized in that, The method further includes: When the Android system boots for the first time, it generates a unique fingerprint for the Android terminal device, binds the unique fingerprint to the customer's digital certificate, stores it in the custom partition directory, and uploads it to the cloud security database. Establish a baseline for the startup behavior of Android terminal devices, including CPU usage curves, memory loading rates, and frequency of access to custom partition files during normal startup. During each startup process, the current startup behavior is compared with the startup behavior baseline in real time. If an anomaly is detected, a security protection mechanism is immediately triggered. The security protection mechanism includes pausing the loading of customized resources, locking access permissions to the custom partition, and prompting the administrator to perform device unique fingerprint verification via a local pop-up window on the Android terminal device.

9. The Android booting method of claim 8, wherein, When a customer changes their customization requirements and needs to re-flash resources, the administrator is required to provide both the new customer's digital certificate and the device's unique fingerprint in the cloud security database for dual verification. Only after successful dual verification is it allowed to erase the original files in the custom partition and the custom_logo partition.

Images