A method for protecting and restoring login credentials in application data cleanup

Abstract

This invention discloses a method for protecting and restoring login credentials during application data cleanup, comprising: after successful application login, backing up the application's login credentials to a protected storage area via a secure interface; responding to a data cleanup request, identifying the application with backed-up login credentials, and performing a data cleanup operation; after the data cleanup operation is completed, reading the backed-up login credentials from the protected storage area, and automatically restoring the backed-up login credentials to the application data directory. This invention supports multi-level protection strategies, encrypted storage, dual-mode recovery, and batch configuration, enabling automatic recovery without user awareness while maximizing storage space release, ensuring account security, and improving user experience.

Description

Technical Field

[0001] This invention relates to the field of application data processing technology, and in particular to a method for protecting and restoring login credentials during application data cleanup. Background Technology

[0002] Embedded devices (including smart TVs, set-top boxes, mobile phones, public displays, and in-vehicle devices), especially those running Android, are frequently criticized for accumulating a lot of application data after running for a period of time, leading to insufficient disk space and system lag. To address this, users need to periodically clean up application data, typically using the following methods:

[0003] Cache cleanup: Only deletes the application cache directory (such as / data / data / package name / cache), without affecting application private data.

[0004] Clear all data: Use the native clearing method, which means that vouchers will not be automatically restored after clearing.

[0005] Built-in cleanup by the app: The implementation varies from app to app. It usually only cleans up regular cache and some junk files. You need to manually trigger a deep cleanup.

[0006] The aforementioned existing technologies have the following main drawbacks:

[0007] Clearing cache space offers limited space release; clearing all data, while freeing up significant space, also erases user login information, requiring users to re-enter it; application-specific cleanup lacks a unified standard, requiring users to manage each application individually and choose which files / directories to delete, but this is prone to accidental deletion and cumbersome. The core pain point: Users rely on the "remember password" function, and after prolonged passwordless login, they forget their passwords. Data cleanup cannot restore their login status, leading to account lockout or the tedious process of password retrieval.

[0008] Specifically, the existing technologies for backing up and restoring local credentials are as follows:

[0009] Android's native backup (BackupManager) relies on Google services and is not available in China; moreover, this technology is mainly aimed at "device switching and migration" scenarios, rather than "local data cleanup" scenarios, and there are fundamental differences between the two in terms of technical implementation and user needs.

[0010] The app automatically logs in, and the password is stored in SharedPreferences. It is deleted when the data is cleared, so it cannot be automatically recovered.

[0011] Third-party cleanup tools lack the permission to read application private data and cannot achieve automatic recovery; for example, Google's "Recover Credentials" API is mainly for device migration scenarios and is not applicable to scenarios where applications are deleted or data is cleaned up.

[0012] In summary, how to maximize the release of device storage space while securely and automatically protecting and restoring application login credentials, and avoiding the predicament of users having to log in again or forget their passwords due to data cleanup, is a pressing technical problem that needs to be solved. This invention is proposed against this background. Summary of the Invention

[0013] The purpose of this invention is to provide a method for protecting and restoring login credentials during application data cleanup.

[0014] The technical solution adopted in this invention is:

[0015] A method for protecting and restoring login credentials during application data cleanup, comprising:

[0016] After successful application login, the application's login credentials are backed up to a protected storage area via a secure interface;

[0017] In response to a data cleanup request, identify applications that have backed up their login credentials and perform data cleanup operations;

[0018] After the data cleanup operation is completed, the backed-up login credentials are read from the protected storage area and automatically restored to the application data directory.

[0019] Furthermore, the protected storage area is physically isolated from the application's user data directory; the login credentials are stored encrypted during backup, and the encryption key used for encryption is derived from the device's unique identifier; the device's unique identifier includes at least one of the device serial number, Android ID, or hardware identifier.

[0020] Furthermore, the encrypted storage supports multiple encryption algorithms, including international algorithms and Chinese national cryptographic algorithms;

[0021] The international algorithm includes AES-256-GCM;

[0022] The national cryptographic algorithm includes at least one of the following: SM4 symmetric encryption algorithm, SM3 cryptographic hash algorithm and SM2 elliptic curve public key cryptography algorithm;

[0023] The choice of the encryption algorithm is determined by one of the following methods:

[0024] Pre-configure default algorithms based on the compliance requirements of the target market for the equipment;

[0025] It is specified by the application through parameters when calling the backup interface;

[0026] The optimal algorithm is automatically selected based on the device's hardware capabilities.

[0027] Furthermore, when using the national cryptographic algorithm system, the encryption key is derived from the device's unique identifier by a key derivation function based on SM3, the credential data is encrypted using the SM4-GCM mode, and the integrity verification uses the HMAC-SM3 algorithm.

[0028] Furthermore, the steps for automatically restoring the backed-up login credentials to the application data directory specifically include:

[0029] When the application starts, check if a valid login credential exists in the application data directory;

[0030] If no valid login credentials exist, the backup query interface is called to determine whether the backup login credentials for the corresponding application exist in the protected storage area.

[0031] If backup login credentials exist, read the backup login credentials from the protected storage area and restore them to the application data directory.

[0032] Furthermore, the backup query interface is actively called by the application during the startup process, and the recovery operation is completed within the application process. During recovery, only the data directory of the calling application is written, without involving writing operations to the data directories of other applications, thus following the application sandbox isolation mechanism.

[0033] Furthermore, the present invention also includes a dual-mode recovery mechanism:

[0034] When the data cleanup operation is performed by a system cleanup tool that integrates login credential recovery functionality, the system cleanup tool will immediately perform login credential recovery after the cleanup is completed.

[0035] When data cleanup is performed by a system cleanup tool that does not integrate login credential recovery functionality, the application will proactively perform login credential recovery upon detecting the absence of local login credentials upon the next startup.

[0036] The two recovery methods work together, and if one method fails, the other method is used as a supplement.

[0037] Furthermore, the present invention also includes:

[0038] Configure protection flags for the application, which include at least three levels of data cleanup strategies:

[0039] Level 1 strategy: Instructs that cleanup is prohibited, and the cleanup operation skips all data in the application;

[0040] Level 2 policy: Indicates that cleanup is allowed but login credentials should be restored. Login credentials should be automatically restored from the protected storage area after cleanup.

[0041] Level 3 policy: Instructs that cleanup is allowed and that login credentials be cleaned up, and that backup login credentials in the protected storage area be deleted after cleanup.

[0042] In response to a data cleanup request, the corresponding cleanup operation is performed based on the current policy value of the protection flag.

[0043] Furthermore, the present invention also includes a secondary confirmation mechanism: when the user modifies the value of the protection flag, a comparison of the strategy before and after the modification is displayed, and the user is requested to confirm before the modification takes effect.

[0044] Furthermore, the present invention also includes a batch configuration function: it supports users to select multiple applications and uniformly set the value of the protection flag bit.

[0045] The present invention adopts the above technical solution and has the following beneficial technical effects:

[0046] This invention solves the fundamental contradiction of "the incompatibility between space release and login protection" in existing technologies by using technologies such as automatic credential backup, protected storage isolation, dual-mode recovery mechanism, encrypted security, and application sandbox compatibility. It has the following outstanding advantages: full cleanup maximizes space release, and automatic credential recovery is seamless for users; it is implemented purely locally without cloud dependency, making it widely applicable; the application-active recovery mode follows the sandbox isolation mechanism, does not compromise system security, and has high architectural security; and it fills the technical gap in credential protection in local data cleanup scenarios. Attached Figure Description

[0047] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments;

[0048] Figure 1 This is a schematic diagram of the data processing flow of the present invention;

[0049] Figure 2 This is a schematic diagram of the overall architecture of the present invention;

[0050] Figure 3 This is an architecture diagram for an application-based proactive credential recovery solution. Detailed Implementation

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

[0052] A method for protecting and restoring login credentials during application data cleanup, comprising:

[0053] After successful application login, the application's login credentials are backed up to a protected storage area via a secure interface;

[0054] In response to a data cleanup request, identify applications that have backed up their login credentials and perform data cleanup operations;

[0055] After the data cleanup operation is completed, the backed-up login credentials are read from the protected storage area and automatically restored to the application data directory.

[0056] Furthermore, the protected storage area is physically isolated from the application's user data directory; the login credentials are stored encrypted during backup, and the encryption key used for encryption is derived from the device's unique identifier; the device's unique identifier includes at least one of the device serial number, Android ID, or hardware identifier.

[0057] Furthermore, the encrypted storage supports multiple encryption algorithms, including international algorithms and Chinese national cryptographic algorithms;

[0058] The international algorithm includes AES-256-GCM;

[0059] The national cryptographic algorithm includes at least one of the following: SM4 symmetric encryption algorithm, SM3 cryptographic hash algorithm and SM2 elliptic curve public key cryptography algorithm;

[0060] The choice of the encryption algorithm is determined by one of the following methods:

[0061] Pre-configure default algorithms based on the compliance requirements of the target market for the equipment;

[0062] It is specified by the application through parameters when calling the backup interface;

[0063] The optimal algorithm is automatically selected based on the device's hardware capabilities.

[0064] Furthermore, when using the national cryptographic algorithm system, the encryption key is derived from the device's unique identifier by a key derivation function based on SM3, the credential data is encrypted using the SM4-GCM mode, and the integrity verification uses the HMAC-SM3 algorithm.

[0065] Furthermore, the steps for automatically restoring the backed-up login credentials to the application data directory specifically include:

[0066] When the application starts, check if a valid login credential exists in the application data directory;

[0067] If no valid login credentials exist, the backup query interface is called to determine whether the backup login credentials for the corresponding application exist in the protected storage area.

[0068] If backup login credentials exist, read the backup login credentials from the protected storage area and restore them to the application data directory.

[0069] Furthermore, the backup query interface is actively called by the application during the startup process, and the recovery operation is completed within the application process. During recovery, only the data directory of the calling application is written, without involving writing operations to the data directories of other applications, thus following the application sandbox isolation mechanism.

[0070] Furthermore, the present invention also includes a dual-mode recovery mechanism:

[0071] When the data cleanup operation is performed by a system cleanup tool that integrates login credential recovery functionality, the system cleanup tool will immediately perform login credential recovery after the cleanup is completed.

[0072] When data cleanup is performed by a system cleanup tool that does not integrate login credential recovery functionality, the application will proactively perform login credential recovery upon detecting the absence of local login credentials upon the next startup.

[0073] The two recovery methods work together, and if one method fails, the other method is used as a supplement.

[0074] Furthermore, the present invention also includes:

[0075] Configure protection flags for the application, which include at least three levels of data cleanup strategies:

[0076] Level 1 strategy: Instructs that cleanup is prohibited, and the cleanup operation skips all data in the application;

[0077] Level 2 policy: Indicates that cleanup is allowed but login credentials should be restored. Login credentials should be automatically restored from the protected storage area after cleanup.

[0078] Level 3 policy: Instructs that cleanup is allowed and that login credentials be cleaned up, and that backup login credentials in the protected storage area be deleted after cleanup.

[0079] In response to a data cleanup request, the corresponding cleanup operation is performed based on the current policy value of the protection flag.

[0080] Furthermore, the present invention also includes a secondary confirmation mechanism: when the user modifies the value of the protection flag, a comparison of the strategy before and after the modification is displayed, and the user is requested to confirm before the modification takes effect.

[0081] Furthermore, the present invention also includes a batch configuration function: it supports users to select multiple applications and uniformly set the value of the protection flag bit.

[0082] The following content describes the solution of the present invention:

[0083] I. Overall Architecture

[0084] This invention aims to achieve worry-free data cleanup by providing an application password backup and recovery interface with data protection functions, automatically backing up passwords upon application login and automatically restoring them after data cleanup. Its core functions include automatic backup, tag protection, and automatic recovery.

[0085] Automatic backup: When logging into the application, the login credentials (Token / encrypted password) are backed up to a protected area via a secure interface.

[0086] Tag Protection: Configure protection policies for applications, supporting three levels of policies: prohibit cleanup, cleanup and restore credentials, and cleanup and delete credentials.

[0087] Automatic recovery: After the cleanup is complete, the system will automatically restore the user's login credentials, achieving a seamless cleanup.

[0088] As shown in Table 1 below, the main differences between Worry-Free Cleanup and existing technologies such as cache cleanup and cleanup of all, in terms of technical implementation, data processing scope, and credential protection mechanism, are that Worry-Free Cleanup realizes automatic backup and recovery of credential data without requiring any additional operation from the user.

[0089] Table 1. Data Cleaning Techniques

[0090] Cache clearing Delete only the application cache directory Only temporary files are deleted; application private data is not affected. Credentials are stored in SharedPreferences and are unaffected. Clean up all Delete application's complete data directory Delete all application data, including SharedPreferences, databases, etc. The credentials have been deleted and cannot be recovered. Worry-free cleaning Delete application's complete data directory + automatically restore credentials Delete all application data, but retain backup login credentials in the protected area. The voucher will be automatically restored to its original position.

[0091] like Figure 1 As shown, the worry-free data cleanup process is as follows: first login to the application → automatic backup of credentials → user triggers the cleanup process → deletion of the entire data directory → dual-mode credential recovery mechanism → restoration of credentials to their original location → completion.

[0092] like Figure 2 As shown, the overall architecture of this invention consists of four layers: application layer, interface layer, core processing layer, and data storage layer.

[0093] The application layer includes various applications installed on the device (such as video-on-demand applications, social applications, banking applications, etc.), as well as system cleaning tools (such as the storage cleaning function in system settings and third-party cleaning applications).

[0094] The interface layer is divided into two categories: application-side interfaces and cleanup tool-side interfaces, providing standardized APIs for upper-layer callers.

[0095] The core processing layer is the core of the technical solution of this invention, and is responsible for executing key logic such as credential backup, recovery, encryption, policy decision-making and exception handling.

[0096] The data storage layer is independent of the application data directory and uses physical isolation to store credentials and policy configurations.

[0097] II. Application Programming Interface Design

[0098] This invention provides a complete set of application programming interfaces (APIs) for application developers and system cleanup tools to use. The interfaces are divided into two categories: application-side interfaces and cleanup tool-side interfaces.

[0099] Application-side interface: Provided for integration and calls by system applications and third-party applications to implement login credential backup and recovery functions. This interface includes the following core methods:

[0100] (1) Login credential backup method

[0101] This method is invoked by the application after a user successfully logs in and is used to back up login credentials to a protected storage area. This method accepts the input parameters listed in Table 2:

[0102] Table 2 Input parameters for login credential backup method

[0103] Application package name String The package name of the calling application is used to identify the application to which the credentials belong. voucher object Structured data It contains complete information about the login credentials, specifically including: credential type, credential data, expiration time, user identifier, and other fields. Worry-free cleaning Delete application's complete data directory + automatically restore credentials Delete all application data, but retain backup login credentials in the protected area.

[0104] This method performs the following processing flow:

[0105] First, verify the consistency between the caller application's signature and package name to prevent malicious applications from impersonating the backup. Then, serialize the credential data and convert it into a unified storage format. Next, call the encryption module to encrypt the serialized data, generating ciphertext and an integrity check value. Finally, write the encrypted credential to the protected storage area and update the backup timestamp. Return the operation result, including success status or failure reason.

[0106] (2) Login credential recovery method:

[0107] This method is invoked by the application at startup to restore backed-up login credentials from a protected storage area. This method accepts the input parameters listed in Table 3:

[0108] Table 3 Input parameters for login credential recovery method

[0109] Application package name String The package name of the calling application is used to locate the corresponding backup login credentials.

[0110] The method performs the following processing flow: First, it verifies the consistency between the signature and package name of the calling application; then, it reads the encrypted credential data of the corresponding application package name from the protected storage area; next, it calls the decryption module to decrypt the ciphertext and verify its integrity; it deserializes the decrypted data to restore it to a credential object; and returns the credential object, or returns null if there is no backup or decryption fails.

[0111] (3) Methods for checking the existence of vouchers

[0112] This method is used to query whether a backup of login credentials exists for a specified application, allowing the application to determine whether to guide the user to log in during interface display. The method accepts the application package name as input and returns a boolean value indicating whether a backup exists.

[0113] (4) Protection strategy setting method

[0114] This method is used to set or modify the protection policy for a specified application. The method accepts the input parameters listed in Table 4:

[0115] Table 4 Input parameters for protection strategy setting method

[0116] Application package name String Application package name to be set to protected status Data cleaning strategy Enumeration type This indicates how the application should handle data cleanup operations. Possible values ​​include: first value (cleanup prohibited), second value (cleanup allowed but credentials restored), and third value (cleanup allowed and credentials cleaned). Cache cleanup strategy Enumeration type (optional) Indicates how the application should handle cache cleanup operations. Backup strategy Enumeration type (optional) Indicates whether the application allows automatic backup of login credentials.

[0117] When this method is executed, the above policy value is written into the protection flag table, and the setting time and user modification flag are recorded.

[0118] (5) Protection strategy query method

[0119] This method is used to query the current protection policy of a specified application and returns a policy object containing the following information: data cleanup policy value, cache cleanup policy value, backup policy value, and the setting time and modification source of each policy.

[0120] Cleanup tool side interface: This interface is called by system settings applications or third-party cleanup tools to perform data cleanup and obtain cleanup decision information. The interface includes the following core methods:

[0121] (1) Cleanup execution method

[0122] This method is used to trigger data cleanup operations and is the main entry point for the cleanup tool. This method accepts the input parameters listed in Table 5:

[0123] Table 5 Input parameters for the cleanup execution method

[0124] Cleanup type Enumeration type Specify the scope of the cleanup, including: full cleanup (clean up all data of all applications), cache-only cleanup (clean up only the cache directory), and custom cleanup (clean up a specified list of applications). Application list String list When the cleanup type is custom cleanup, specify the list of application package names to be cleaned; for other cleanup types, this parameter can be empty.

[0125] The method executes the following processing flow: First, a list of applications to be processed is determined based on the cleanup type. Second, for each application in the list, the protection policy query method is called to obtain the protection policy configuration for that application, and differentiated cleanup operations are performed according to the protection policy. For a detailed description of the specific cleanup decision algorithm and policy execution logic, please refer to Part Five, "User-defined Protection Policies." Then, for applications determined to be "allowed for cleanup but credential restoration," the login credential restoration method is automatically called after cleanup is completed, and the backed-up login credential is written back to the application data directory. The cleanup history is recorded in the cleanup history table; the cleanup results are returned, including the amount of space released, the number of applications cleaned, the number of successfully restored credentials, and a list of applications that failed to restore.

[0126] This method only defines the interface specifications and calling method for the cleanup operation. For the specific cleanup decision algorithm (including the judgment logic of each protection policy value, the processing branches of different cleanup types, and the data recovery rules after cleanup), please refer to the detailed description in Part 5 "User-defined protection policies".

[0127] (2) Cleanup application query method

[0128] This method retrieves a list of applications that are currently safe to clean up, which the cleanup tool uses when displaying the estimated free space in the user interface. This method requires no input parameters and returns a list of applications that may include the following information: application package name, application name, size of space occupied, whether there is a backup of login credentials, and whether it is safe to clean up.

[0129] (3) Method for querying the list of protected applications

[0130] This method retrieves a list of applications currently marked as protected, providing the cleanup tool with a user-manageable list of protected applications. The method returns a list of applications containing the following information: application package name, application name, protection status, reason for protection, and whether it was manually set by the user.

[0131] (4) Method for clearing historical queries

[0132] This method is used to retrieve historical cleanup records, allowing users to track the cleanup results. It accepts a query limit as input and returns a specified number of historical cleanup records. Each record contains information such as cleanup time, cleanup type, amount of space released, number of applications cleaned, and number of successfully restored credentials.

[0133] Data structure definition: The voucher object involved in the above interface methods is defined as structured data containing the following fields, as shown in Table 6.

[0134] Table 6 Data Structure Definitions

[0135] voucher type String The types of identification credentials, and their possible values ​​include, but are not limited to: authentication tokens, passwords, and session identifiers. voucher data String The core content of the credentials is the token string for authentication tokens and the encrypted password for passwords. Expiration time Timestamp The expiration date of a voucher is used to determine whether the voucher needs to be updated. User ID String The associated user account identifier is used to distinguish credentials in multi-account scenarios. Extended fields key-value pair set Reserved extended fields for applications to store additional information.

[0136] The return values ​​of the above interface methods are as follows: for successful operations, the operation result and the corresponding data object are returned; for failed operations, the error code and error description are returned, which makes it easier for the caller to handle abnormal situations.

[0137] To more clearly illustrate how to use the interface described in this invention, the following describes a typical interface call flow:

[0138] (1) Application integration process

[0139] When application developers integrate the SDK of this invention into the application login module, they should follow the following process:

[0140] When the application starts, the credential existence check method is called to determine whether a backup login credential exists. If a backup login credential exists, the credential recovery method is called to obtain the credential data and complete the automatic login directly. If no backup login credential exists, the user is guided to enter their account and password to complete the login. After the user logs in successfully, the credential backup method is called to back up the login credential to the protected storage area. Optionally, the protection policy setting method is called to configure an appropriate data cleanup policy for the application.

[0141] (2) Cleanup tool call process

[0142] When a user triggers a cleanup operation, the system cleanup tool follows this process:

[0143] The system calls the protected application list query method to obtain the current list of protected applications and displays it on the user interface; it calls the cleanupable application query method to obtain the list of applications that can be safely cleaned and calculates the expected space to be released; after the user confirms the cleanup, it calls the cleanup execution method, passing in the cleanup type selected by the user; after the cleanup execution method completes data cleanup and credential recovery, it returns the cleanup result; the cleanup tool updates the user interface based on the returned result, prompting the user about the cleanup effect and the applications that require manual login.

[0144] III. Dual-mode recovery mechanism

[0145] This invention employs a dual-mode recovery mechanism, including a mode that actively recovers credentials and a mode that automatically backs up and restores data using a cleanup program. For example... Figure 3 As shown, the data flow of the application actively restoring credentials mode is as follows: After successful application login, the login credentials are backed up to the protected storage area through a security interface; in response to the data cleanup request, the application with the backed-up login credentials is identified and the data cleanup operation is performed; after the cleanup is completed, the application actively reads the backed-up login credentials from the protected storage area and automatically restores them to the application data directory after detecting that there are no credentials locally when it starts up for the first time.

[0146] The automatic backup and restore mode of the cleanup program means that after the cleanup is completed, the system cleanup tool will immediately read the backup login credentials from the protected storage area and automatically restore them to the application data directory.

[0147] IV. Voucher Encryption Storage Mechanism

[0148] To ensure the security of stored credentials, this invention employs a layered encryption mechanism to protect login credentials. The encryption mechanism includes the following components:

[0149] (1) Key derivation function

[0150] The encryption key is generated from the device's unique identifier combined with optional user authentication information through a key derivation function. Specifically, the key derivation function is calculated as follows:

[0151] Base key: A fixed-length base key material is generated by using a unique device identifier (including but not limited to Android ID, device serial number, and hardware identifier) ​​as input and a cryptographic hash function.

[0152] Enhanced key: When a user sets a lock screen password or the application belongs to a high-security category (such as banking applications), the user's lock screen password is added as an additional input to the basic key, and an enhanced key is generated through a key derivation function;

[0153] Key storage: The derived key is not stored persistently. It is calculated and generated in real time each time encryption and decryption are needed to avoid the risk of key leakage.

[0154] (2) Encryption algorithm

[0155] The credential data is protected using an authentication encryption algorithm. This invention supports multiple encryption algorithms, and users or systems can select the appropriate algorithm based on compliance requirements and performance needs. The encryption algorithm configuration adopts a pluggable design, specifically including the algorithm options listed in Table 7:

[0156] Table 7 Encryption Algorithm Options

[0157] Symmetric encryption AES-256-GCM 256-bit General scenarios, international compatibility Symmetric encryption SM4-GCM 128-bit National cryptographic compliance scenarios and domestic production environment Asymmetric encryption ECDSA 256-bit Key negotiation, signature verification Asymmetric encryption SM2 256-bit Identity authentication, key negotiation Key Derivation PBKDF2 256-bit General scenarios Key Derivation National Cryptography KDF 256-bit National cryptographic compliance scenarios Integrity verification HMAC-SHA256 256-bit General scenarios Integrity verification HMAC-SM3 256-bit National cryptographic compliance scenarios

[0158] The system provides the following algorithm selection methods:

[0159] System-level default configuration: When the device leaves the factory, the default encryption algorithm is pre-configured according to the compliance requirements of the target market. For example, devices for the domestic market: the default is to use the Chinese cryptographic algorithm combination of SM4-GCM+SM3-HMAC+SM2 key negotiation; devices for the international market: the default is to use the international algorithm combination of AES-256-GCM+SHA256-HMAC.

[0160] Application-level dynamic selection: When calling the backup interface, the application can specify its preferred encryption algorithm through parameters.

[0161] Runtime adaptive selection: The system automatically selects the optimal algorithm based on the device's hardware capabilities; if the device integrates a national cryptographic hardware acceleration module (such as a domestic chip that supports the SM4 instruction set), the national cryptographic algorithm is used first to improve performance; if the device does not have national cryptographic hardware support, the AES-256-GCM algorithm is used to ensure compatibility.

[0162] To avoid algorithm selection conflicts, this invention determines the final encryption algorithm to be used according to the priority order in Table 8:

[0163] Table 8 Priority of Encryption Algorithm Selection

[0164] Highest Application-level dynamic selection Applications can explicitly specify algorithms through the SDK interface. Second highest System-level default configuration The application did not specify an algorithm; the system has already configured a default algorithm. lowest Runtime adaptive selection The application did not specify an algorithm, and the system did not configure a default algorithm.

[0165] (3) Storage format

[0166] The encrypted credential data is stored in the protected area in the following format:

[0167] [Version Number][Initialization Vector][Authentication Tag][Encrypted Ciphertext];

[0168] The version number is used to identify the version of the encryption algorithm, which facilitates compatibility handling during subsequent algorithm upgrades.

[0169] V. User-defined protection policies

[0170] This invention provides a cleanup decision-making method based on multi-level protection flags. This method performs differentiated data processing operations for different cleanup scenarios according to a user-preset protection strategy. The decision algorithm logic described in this section corresponds to the core processing logic called in the aforementioned "cleanup execution method." Specifically, the cleanup decision-making process includes the following steps:

[0171] (a) Cleanup request receiving steps

[0172] The system cleanup tool receives cleanup requests triggered by users, and these requests include cleanup type parameters. The cleanup types include, but are not limited to: a full cleanup type, used to clean up all application data; a cache cleanup type, used only to clean up the application's cache directory; and a custom cleanup type, used to clean up a user-specified list of applications.

[0173] (II) Steps for reading protection policies

[0174] In response to the cleanup request, the system iterates through all installed applications and, for each application, reads the corresponding protection policy configuration from the protection flag table. The protection policy configuration includes at least a data cleanup policy field, which indicates how the application will be processed during the data cleanup operation.

[0175] (III) Cleanup Type Determination Steps

[0176] The system determines the type of cleanup operation based on the cleanup type parameter in the cleanup request and selects the corresponding decision branch: if the cleanup type is full cleanup, it reads the data cleanup strategy field of each application to make a decision; if the cleanup type is cache cleanup, it reads the cache cleanup strategy field of each application to make a decision; if the cleanup type is custom cleanup, it determines the cleanup scope based on the list of applications specified by the user.

[0177] (iv) Data cleaning strategy decision-making steps

[0178] For a full cleanup operation, the system performs the following decision based on the value of the data cleanup strategy field:

[0179] When the data cleanup policy field is set to the first value (i.e., "cleanup prohibited"), the system determines that the application is in a protected state, skips all data of the application, does not perform any cleanup operations, and retains the application's login credentials, user configurations, and other data intact.

[0180] When the data cleanup policy field is the second value (i.e., "Allow cleanup but restore credentials"), the system determines that the application is safe to clean up and performs the following sub-steps: First, delete all data directories of the application, including application private data, shared preferences, database files, etc.; Second, after cleanup is completed, read the backup login credentials corresponding to the application from the protected storage area; Then, decrypt the backup login credentials and restore them to the original location in the application data directory; Finally, record the status that the application has successfully restored credentials.

[0181] When the data cleanup policy field is the third value (i.e., "Allow cleanup and clean up credentials"), the system determines that the application is in a fully cleaned state and performs the following sub-steps: First, delete all data directories of the application; second, delete the backup login credential file corresponding to the application from the protected storage area; finally, record the application's fully cleaned state, and the user will need to log in again the next time the application is launched.

[0182] (v) Cache cleanup strategy decision-making steps

[0183] For cache cleanup operations, the system makes decisions based on the value of the cache cleanup policy field: when the cache cleanup policy field is the first value (i.e., "disable cache cleanup"), the system skips the application's cache directory; when the cache cleanup policy field is the second value (i.e., "allow cache cleanup"), the system deletes all temporary files in the application's cache directory.

[0184] (vi) Results Summary and Notification Procedures

[0185] After all applications have been processed, the system summarizes the cleanup results and generates a cleanup report. The cleanup report includes: the amount of storage space released, the number of applications cleaned, the number of applications whose credentials were successfully restored, the number of applications skipped due to policy restrictions, and a list of applications that failed to be restored. The system presents the cleanup report to the user as a notification.

[0186] The decision-making algorithm logic described in this section is invoked at runtime by the aforementioned "cleanup execution method". Through the above decision-making process, this invention achieves differentiated cleanup control based on user-preset strategies. Users can flexibly configure cleanup behavior according to the importance of the application, achieving a balance between releasing storage space and protecting important data.

[0187] Compared with the prior art, the present invention has the following technical features in terms of the protection flag mechanism:

[0188] (I) Multi-level protection strategy

[0189] This invention applies data protection not by using the commonly used binary protection flag (which only supports "protected" and "not protected" states), but by expanding the protection flag into a multi-level policy system, thereby expressing the user's more refined protection intent.

[0190] Specifically, the present invention sets a data cleanup policy field in the protection flag table. This field supports at least three values: the first value corresponds to the "disable cleanup" policy, which instructs the system to completely skip all data of the application during the cleanup operation; the second value corresponds to the "allow cleanup but restore credentials" policy, which instructs the system to automatically restore login credentials from the protected storage area after cleanup of all data; and the third value corresponds to the "allow cleanup and clean up credentials" policy, which instructs the system to delete the backup login credentials in the protected storage area while cleanup of all data.

[0191] Through the multi-level strategy design described above, users can choose different protection levels based on the importance of the application and their usage habits: for important applications such as banking applications, the "disallow cleanup" strategy can be selected; for frequently used video and social applications, the "allow cleanup but restore credentials" strategy can be selected; for applications that are not frequently used or do not require retaining login status, the "allow cleanup and clean up credentials" strategy can be selected. This design overcomes the technical problems of coarse protection granularity and limited user choice in existing technologies.

[0192] (II) Scenario-based strategy configuration

[0193] This invention does not employ a globally unified configuration, meaning that the same application executes the same processing logic in all cleanup scenarios, failing to differentiate the varying needs of different operation scenarios such as full cleanup, cache cleanup, and application uninstallation. Instead, it sets policy fields for different scenarios in the protection flag table, including: a data cleanup policy field to control the behavior of full cleanup operations; a cache cleanup policy field to control the behavior of cache cleanup operations; a backup policy field to control the behavior of automatic credential backup; and an uninstallation policy field to control whether backup login credentials are retained when the application is uninstalled.

[0194] Through the aforementioned scenario-based policy configuration, users can set different processing methods for the same application under different operating scenarios. For example, a user can configure an application to "allow cleanup but restore credentials" during a full cleanup, "allow cache cleanup" during cache cleanup, and "retain backup login credentials" during application uninstallation so that login can be restored after reinstallation. This design achieves scenario-based and fine-grained control of protection policies, overcoming the technical problems of existing technologies that have single policies and cannot adapt to the needs of multiple scenarios.

[0195] (III) Secondary Confirmation Mechanism

[0196] In existing technologies, changes to the protection flag take effect immediately without any confirmation step. Since modifications to the protection flag directly affect data cleanup, accidental operations may result in the unintended deletion of important data or unnecessary occupation of storage space.

[0197] To address this technical deficiency, this invention introduces a secondary confirmation mechanism. Specifically, when a user modifies the value of any protection policy field through the user interface, the system performs the following operations: First, it reads the original policy value before the modification; second, it generates policy change comparison information to visually demonstrate the differences between the original and new policies to the user; then, it displays a confirmation dialog box to prompt the user to confirm the modification; finally, only after the user confirms will the system write the new policy value into the protection flag table.

[0198] The confirmation dialog box may also include a "Don't prompt again" option. When the user selects this option, subsequent modifications to the same application's policy will no longer trigger a confirmation dialog box, and the user's preset default behavior will be executed directly. This design strikes a balance between preventing accidental operations and reducing the user's operational burden, overcoming the technical problems of lacking a confirmation mechanism and having a high risk of accidental operations in existing technologies.

[0199] (iv) Batch configuration function

[0200] When a large number of applications are installed on a device, setting protection flags for each application individually is costly and inefficient. Therefore, this invention provides a batch configuration function.

[0201] Specifically, the system provides a batch management entry point in the user interface. After entering batch management mode, the interface displays a list of installed applications, with checkboxes next to each application for the user to select. Users can perform the following operations: check the applications that need to be configured one by one; click the "Select All" button to select all applications at once; or click the "Recommend Protection" button, which will allow the system to automatically identify and recommend applications that should be protected (such as applications with backup login credentials or frequently used applications).

[0202] After the user selects the applications, they choose the policy type and value to be configured in batches. The system then writes the selected policy values ​​into the protection flag table of all selected applications. Once batch configuration is complete, the system returns a configuration result report, including the number of successfully configured applications and a list of failed configurations. This design significantly improves configuration efficiency, particularly in device initialization or batch deployment scenarios, overcoming the low configuration efficiency issues of existing technologies.

[0203] (v) Policy persistent storage

[0204] This invention persistently stores user-configured protection policies in a protection flag table. This table is independent of the application data directory and is not deleted during system restarts, application updates, system upgrades, or other operations. Once configured by the user, the policy remains effective indefinitely and does not require repeated configuration.

[0205] Specifically, each record in the protection flag table includes the application package name, the values ​​of each policy field, the setting time, the last modification time, and a user modification flag. The user modification flag distinguishes between user-defined policies and system default policies, facilitating priority-based decision-making in case of policy conflicts. This design ensures the persistence and traceability of user configurations.

[0206] (vi) Strategy Conflict Handling Mechanism

[0207] When multiple policy sources exist for the same application (such as system default policy, user-defined policy, and application-recommended policy), this invention handles conflicts according to a preset priority rule. Specifically, user-defined policies have the highest priority, followed by policies recommended by the application through the SDK interface, and finally the system default policy. This priority rule ensures that users' right to choose is fully respected, while providing reasonable default behavior for application developers and the system.

[0208] VI. Credential Cleanup Mechanism After Application Uninstallation

[0209] The process of credential cleanup mechanism after application uninstallation is as follows: The system listens for application uninstallation events; when an application is detected to be uninstalled, the SDK automatically cleans up the application's backup login credentials; the cleanup history records that the application's credentials have been cleaned up; and useless credentials are prevented from occupying storage space.

[0210] VII. Abnormal Scenario Handling Mechanism:

[0211] 1. Device Power Outage Interruption Handling: For abnormal scenarios where the device suddenly loses power during the cleanup process, interrupting the cleanup operation, the following exception handling mechanism can be adopted: The SDK creates a cleanup transaction record before cleanup begins and marks it as "in progress"; after the power outage restarts, the system detects the incomplete cleanup transaction; the SDK automatically resumes the cleanup transaction and re-executes the incomplete cleanup and recovery operations; after the cleanup is completed, the transaction mark is updated to "completed".

[0212] 2. Backup failure due to insufficient storage space: For abnormal scenarios where the device storage space is full and credential backup cannot be completed when logging into the application, the following exception handling mechanism can be adopted: The SDK detects insufficient storage space and returns a backup failure status; the application continues to log in normally, but the credentials are not backed up; the system monitors the storage space periodically and automatically triggers a backup retry when there is sufficient space; users can also manually trigger a backup in the "Application Data Protection" interface.

[0213] VIII. Beneficial Effects

[0214] Maximize free space: Safely clean up all application data, freeing up to several GB of space;

[0215] Seamless User Recovery: Login status is automatically restored after cleanup, without the need to re-enter the password;

[0216] Solving the problem of forgotten passwords: If a user forgets their password after logging in without a password for a long time, it can be automatically recovered after clearing the system.

[0217] Secure and reliable: credentials are encrypted and stored, and devices are bound to prevent data leakage;

[0218] Developer-friendly: Provides a simple SDK interface, resulting in low application integration costs.

[0219] IX. Examples

[0220] This invention employs a worry-free cleanup solution, which is comparable to full cleanup in terms of space release, but significantly superior in terms of user experience. Users do not need to remember passwords or log in to each application individually, achieving a balance between maximizing space release and optimizing user experience.

[0221] Example 1: Automatic Backup of Login Credentials for Smart TV Applications

[0222] This embodiment uses a smart TV device as an example. The device runs on the Android operating system and comes pre-installed with video-on-demand applications (such as a TV version of a video platform). The device has integrated the Worry-Free Cleanup SDK described in this invention, and the system settings include an "Application Data Protection" management interface. The application login and automatic backup process is as follows:

[0223] Step 1: User logs into the application for the first time

[0224] When a user launches the video-on-demand application, the application detects no valid login credentials locally and displays the login screen. The user enters their account (phone number) and password via remote control and clicks the "Login" button.

[0225] Step 2: Apply verification credentials

[0226] The application client sends its account and password to the application server for verification. Upon successful verification, the server returns the following information: Access Token: valid for 30 days; Refresh Token: valid for 180 days; User Identifier: a unique user ID; User Nickname: used for interface display.

[0227] Step 3: The application calls the backup interface.

[0228] After receiving a successful login response, the application calls the SDK interface provided by this invention to back up credentials.

[0229] Step 4: SDK performs backup processing

[0230] After receiving the backup request, the SDK performs the following processing:

[0231] Authentication: Verify the package name and signature of the calling application to confirm its legitimacy and prevent malicious applications from forging backup requests.

[0232] Data serialization: Converts the voucher object into a JSON string format for easier subsequent encryption processing.

[0233] Key Derivation: Read the device's unique identifier (Android ID), combine it with the device serial number, and generate a 256-bit encryption key using the PBKDF2 algorithm.

[0234] Data encryption: The serialized credential data is encrypted using the AES-256-GCM algorithm to generate ciphertext, initialization vector, and authentication tag.

[0235] Storage Write: Writes the encrypted data to the protected storage area at / data / protected_credentials / com.example.videoapp / credential.enc.

[0236] Record backup information: Insert or update records in the protected credentials table, recording backup timestamps and data signatures.

[0237] Step 5: Backup complete

[0238] The SDK returns a backup success status to the application. The application continues to load the main interface normally, and the user can start watching video content. If the user enters the "Application Data Protection" interface in the system settings, they will see that the application is displayed in the list of protected applications, the protection status is "Protected", and a message will be displayed saying "Login status will be retained during cleanup".

[0239] Example 2: System cleanup triggers automatic recovery

[0240] After using a smart TV for six months, the device's storage space gradually becomes full of various application data, and the system prompts "Insufficient storage space, we recommend cleaning up." Users can go to system settings and select the "Storage and Cleanup" function.

[0241] Before cleanup: The device currently has 15 apps installed, occupying approximately 42GB of space. Among them:

[0242] The video-on-demand application occupies 5.2GB (including cached videos, user configurations, etc.); the application's login credentials were backed up to protected storage 30 days ago.

[0243] Clean up the execution process

[0244] Step 1: User triggers cleanup

[0245] The user clicks the "One-Click Cleanup" button on the "Storage and Cleanup" interface. The system then calls the cleanup interface provided by this invention.

[0246] Step 2: Scanning and Classification Decision

[0247] The SDK scans all installed applications and makes decisions for each application, as shown in Table 9:

[0248] Table 9 Examples of Application Cleanup Decisions

[0249] Video on demand Allow cleanup but restore credentials yes Safe cleaning All data Banking applications Cleaning is prohibited yes Skip cleaning Skip cleaning Weather app Allow cleanup but restore credentials no Safe cleaning Safe cleaning Game Applications Allow cleanup and cleanup credentials no Complete cleanup All data

[0250] Step 3: Perform data cleanup

[0251] For applications determined to be "safe to clean", the SDK performs the following operations:

[0252] Delete the application's private data directory: / data / data / com.example.videoapp /

[0253] Delete the application user data directory: / data / user_de / 0 / com.example.videoapp /

[0254] Record the list of applications that have been cleaned up.

[0255] Step 4: Perform credential recovery

[0256] After cleanup is complete, the SDK iterates through the list of cleaned applications and performs recovery for each application with backup login credentials: First, it reads the backup login credentials from the protected storage area; second, it verifies the data integrity using HMAC-SHA256 to confirm that it has not been tampered with; then, it decrypts the data using the derived key to restore the original credential object; next, it writes the credential data back to the application data directory, with the recovery path being / data / data / com.example.videoapp / shared_prefs / login.xml; and it notifies the application that the login credentials have been restored via system broadcast.

[0257] Step 5: Return to cleanup results and user notifications

[0258] The SDK returns the cleanup results to the caller, and the system sends a notification to the user: "12 applications have been cleaned up, freeing up 3.8GB of space, and 8 applications have automatically resumed their login status."

[0259] When a user reopens the video-on-demand application, the application automatically retrieves the restored login credentials; the application automatically logs in and goes directly to the main interface, allowing the user to continue using the application without having to re-enter their account and password.

[0260] Example 3: Batch Application Protection Settings

[0261] Batch setup process

[0262] Step 1: The user enters the batch management interface. On the "Application Data Protection" interface, the user clicks the "Batch Management" button in the upper right corner to enter the batch selection mode.

[0263] Step 2: Select Applications. The interface displays a list of all installed applications, each with a checkbox next to it. Users can: select the applications they want to protect one by one; click the "Select All" button to select all applications; or click the "Recommend Protection" button to have the system automatically recommend applications to be protected (such as logged-in applications).

[0264] Step 3: Confirm Settings. After the user has checked the boxes, click the "Apply" button. The SDK receives the batch setting request, iterates through the selected application list, and calls the protection flag setting interface for each application one by one.

[0265] Step 4: Batch processing results. The SDK returns the batch processing results:

[0266] Successfully set up: 12;

[0267] Number of failures: 0;

[0268] Failure list: empty;

[0269] Step 5: Interface Update. The interface updates to show the protection status of all selected applications as "Under Protection".

[0270] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Without conflict, the embodiments and features described and illustrated herein can be combined with each other. The components of the embodiments of the present invention generally described and illustrated in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments of the present invention is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A method for protecting and restoring login credentials in application data cleanup, characterized by, include: After successful application login, the application's login credentials are backed up to a protected storage area via a secure interface; In response to a data cleanup request, identify applications that have backed up their login credentials and perform data cleanup operations; After the data cleanup operation is completed, the backed-up login credentials are read from the protected storage area and automatically restored to the application data directory.

2. The method for protecting and restoring login credentials in application data cleaning according to claim 1, characterized in that, The protected storage area is physically isolated from the application's user data directory; The login credentials are stored in encrypted form during backup, and the encryption key used for encryption is derived from the device's unique identifier; the device's unique identifier includes at least one of the device serial number, Android ID, or hardware identifier.

3. The method for protecting and restoring login credentials in application data cleanup according to claim 2, characterized in that, The encrypted storage supports multiple encryption algorithms, including international algorithms and Chinese national cryptographic algorithms; The international algorithm includes AES-256-GCM; The national cryptographic algorithm includes at least one of the following: SM4 symmetric encryption algorithm, SM3 cryptographic hash algorithm and SM2 elliptic curve public key cryptography algorithm; The choice of the encryption algorithm is determined by one of the following methods: Pre-configure default algorithms based on the compliance requirements of the target market for the equipment; It is specified by the application through parameters when calling the backup interface; The optimal algorithm is automatically selected based on the device's hardware capabilities.

4. The method for protecting and restoring login credentials in application data cleanup according to claim 3, characterized in that, When using the national cryptographic algorithm system, the encryption key is derived from the device's unique identifier by a key derivation function based on SM3, the credential data is encrypted using the SM4-GCM mode, and the integrity verification uses the HMAC-SM3 algorithm.

5. The method for protecting and restoring login credentials in application data cleanup according to claim 1, characterized in that, The specific steps for automatically restoring backed-up login credentials to the application data directory include: When the application starts, check if a valid login credential exists in the application data directory; If no valid login credentials exist, the backup query interface is called to determine whether the backup login credentials for the corresponding application exist in the protected storage area. If backup login credentials exist, read the backup login credentials from the protected storage area and restore them to the application data directory.

6. The method for protecting and restoring login credentials in application data cleanup according to claim 5, characterized in that, The backup query interface is actively called by the application during the startup process. The recovery operation is completed within the application process. During recovery, only the data directory of the calling application is written, without involving write operations to the data directories of other applications, and follows the application sandbox isolation mechanism.

7. The method for protecting and restoring login credentials in application data cleanup according to claim 5, characterized in that, It also includes a dual-mode recovery mechanism: When the data cleanup operation is performed by a system cleanup tool that integrates login credential recovery functionality, the system cleanup tool will immediately perform login credential recovery after the cleanup is completed. When data cleanup is performed by a system cleanup tool that does not integrate login credential recovery functionality, the application will proactively perform login credential recovery upon detecting the absence of local login credentials upon the next startup. The two recovery methods work together, and if one method fails, the other method is used as a supplement.

8. The method for protecting and restoring login credentials in application data cleanup according to claim 1, characterized in that, Also includes: Configure protection flags for the application, which include at least three levels of data cleanup strategies: Level 1 strategy: Instructs that cleanup is prohibited, and the cleanup operation skips all data in the application; Level 2 policy: Indicates that cleanup is allowed but login credentials should be restored. Login credentials should be automatically restored from the protected storage area after cleanup. Level 3 policy: Instructs that cleanup is allowed and that login credentials be cleaned up, and that backup login credentials in the protected storage area be deleted after cleanup. In response to a data cleanup request, the corresponding cleanup operation is performed based on the current policy value of the protection flag.

9. A method for protecting and restoring login credentials in application data cleanup according to claim 8, characterized in that, It also includes a secondary confirmation mechanism: when a user modifies the value of the protection flag, a comparison of the policy before and after the modification is displayed, and the user is asked to confirm before the modification takes effect.

10. A method for protecting and restoring login credentials in application data cleanup according to claim 8, characterized in that, It also includes a batch configuration function: allowing users to select multiple applications and uniformly set the value of the protection flag.

Images