A non-active user data management method, device, equipment and storage medium

Abstract

The application discloses a kind of non-active user data management method, device and equipment and storage medium, it is related to data management technical field, non-active user data management method includes: configuration non-active user data cleaning strategy, data cleaning strategy defines the determination condition of user active state and at least one data cleaning operation corresponding to determination condition;Periodically monitor the active state of each user according to preset time interval by background service, according to determination condition, identify target user that satisfies data cleaning condition;The data cleaning operation corresponding to determination condition is executed to target user, to release storage space.The application can solve the waste problem of storage space in the multi-user scene of Android operating system in vehicle information entertainment system.

Description

Technical Field

[0001] This application relates to the field of data management technology, specifically to a method, apparatus, device, and storage medium for managing inactive user data. Background Technology

[0002] Prior to Android L, data was not automatically cleared when a user exited the foreground. Starting with Android L, temporary users (such as GUEST users) marked with EPHEMERAL (a type of marker for temporary users in the Android multi-user framework) are automatically removed before and after exiting. That is, for users marked as temporary, the system automatically initiates a user removal and data cleanup process after the user session ends or the user is logged out / exited, thereby reclaiming all storage space and system resources occupied by that user.

[0003] However, data from other types of background users besides GUEST users still consumes system space. Real-world systems contain a large number of non-GUEST background user types. When these users exit the foreground or become inactive, the data and files they generate are not automatically reclaimed by the system, leading to long-term storage issues.

[0004] For IVI (In-Vehicle Infotainment) systems, especially in most cabin usage scenarios such as car sharing, multi-screen multi-user, and auto shows, a large number of users are created. The system will create a separate data directory for each user (e.g., / data / user / ).<user_id> (etc.) to ensure that user data is isolated from each other; as the number of applications and the amount of data increase, the ROM space occupied by this part will increase more and more; and in the above scenario, some users will remain in an inactive state for a long time after switching to the background. The user data of these inactive users will waste a lot of system storage space, especially for mid-to-low-end models with limited ROM space, the impact will be greater. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for managing inactive user data, which can solve the problem of wasted storage space in multi-user scenarios of the Android operating system in in-vehicle infotainment systems.

[0006] In a first aspect, embodiments of this application provide a method for managing inactive user data, the method comprising:

[0007] Configure an inactive user data cleanup strategy, wherein the data cleanup strategy defines the conditions for determining the user's activity status and at least one data cleanup operation corresponding to the conditions;

[0008] The background service periodically monitors the activity status of each user at preset time intervals, and identifies target users who meet the data cleaning conditions based on the judgment criteria.

[0009] Perform data cleanup operations on the target user corresponding to the determination conditions to free up storage space.

[0010] In conjunction with the first aspect, in one implementation, the configuration of the inactive user data cleanup strategy defines a user activity status determination condition and at least one data cleanup operation corresponding to the determination condition, including:

[0011] The determination condition is configured to determine whether the user's inactivity time exceeds a preset threshold;

[0012] If a user remains inactive for more than the first threshold, the user data will be frozen, compressed, and stored, while the user login entry will be retained.

[0013] If a user remains inactive for more than a second threshold, the user data is removed, where the second threshold is greater than the first threshold.

[0014] In conjunction with the first aspect, in one implementation, determining whether the user's inactivity time exceeds a preset threshold includes:

[0015] Obtain the last activity timestamp of each user stored in the in-vehicle infotainment system;

[0016] Calculate the time difference between the current system time and the last activity timestamp to determine whether it exceeds a preset threshold.

[0017] In conjunction with the first aspect, in one implementation, the removal of user data includes removing at least one of user private data, cache, and temporary files.

[0018] In conjunction with the first aspect, in one implementation, the step of periodically monitoring the activity status of each user through a background service at preset time intervals, and identifying target users who meet the data cleanup conditions based on the determination criteria, includes:

[0019] A user data hibernation service runs in the systemserver process, and provides interfaces for data directory compression and decompression;

[0020] Implement an inner class of JobService to periodically check if any users meet the freeze or removal conditions.

[0021] In conjunction with the first aspect, in one implementation, it further includes:

[0022] When a decrease in vehicle usage frequency is detected, the preset time interval for monitoring is shortened; when an increase in vehicle usage frequency is detected, the preset time interval is extended.

[0023] In conjunction with the first aspect, in one implementation, the target users include secondary users, demo users, pre-installed auxiliary users, and / or test accounts.

[0024] Secondly, embodiments of this application provide an inactive user data management device, the inactive user data management device comprising:

[0025] A configuration module is used to configure a data cleanup strategy for inactive users. The data cleanup strategy defines the conditions for determining the user's activity status and at least one data cleanup operation corresponding to the conditions.

[0026] The monitoring module is used to periodically monitor the activity status of each user through a background service at preset time intervals, and identify target users who meet the data cleaning conditions based on the judgment conditions.

[0027] The execution module is used to perform data cleanup operations on the target user corresponding to the judgment conditions in order to release storage space.

[0028] Thirdly, embodiments of this application provide an inactive user data management device, which includes a processor, a memory, and an inactive user data management program stored in the memory and executable by the processor. When the inactive user data management program is executed by the processor, it implements the steps of the inactive user data management method described above.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium storing an inactive user data management program, wherein when the inactive user data management program is executed by a processor, it implements the steps of the inactive user data management method described above.

[0030] The beneficial effects of the technical solutions provided in this application include:

[0031] This application configures an inactive user data cleanup strategy, which defines the conditions for determining a user's activity status and at least one data cleanup operation corresponding to the conditions. The background service periodically monitors the activity status of each user at preset time intervals, identifies target users that meet the data cleanup conditions based on the conditions, and performs data cleanup operations corresponding to the conditions on the target users to free up storage space.

[0032] Therefore, the inactive user data management method described in this application can effectively solve the problem of system resource shortage caused by limited ROM space in in-vehicle infotainment systems. By intelligently identifying and automatically cleaning up inactive user data in multi-user scenarios, it significantly releases storage space and ensures that the system always maintains sufficient available capacity to support critical functions. In particular, by periodically monitoring user activity and performing targeted data cleaning operations, this method not only reduces the risk of OTA update failures caused by insufficient storage space and improves the success rate of vehicle software upgrades, but also reduces the amount of long-term retained sensitive user information, enhancing the data security and privacy protection capabilities of the in-vehicle system. For mid-to-low-end vehicles with limited ROM resources, it can extend the system's lifespan and improve the user experience without increasing hardware costs. Attached Figure Description

[0033] Figure 1 This is a flowchart illustrating an embodiment of the inactive user data management method of this application;

[0034] Figure 2 This is a schematic diagram of the architecture of this application;

[0035] Figure 3 This is a schematic diagram illustrating the core functionality of the UserDataHibernationService in this application;

[0036] Figure 4 This is a schematic diagram of the functional modules of an embodiment of the inactive user data management device of this application;

[0037] Figure 5 This is a schematic diagram of the hardware structure of the inactive user data management device involved in the embodiments of this application. Detailed Implementation

[0038] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0040] In a first aspect, embodiments of this application provide a method for managing inactive user data.

[0041] In one embodiment, reference is made to Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the inactive user data management method of this application. Figure 1 As shown, the methods for managing inactive user data include:

[0042] S1. Configure an inactive user data cleanup strategy, wherein the data cleanup strategy defines the conditions for determining the user's active status and at least one data cleanup operation corresponding to the conditions.

[0043] It is worth noting that in existing technologies, temporary users carrying the EPHEMERAL flag (such as GUEST users) are automatically removed before and after logging out. Key aspects of this mechanism include:

[0044] 1. The system allows users to be associated with the EPHEMERAL flag when creating users, indicating that the user is only used for short-term sessions and should be deleted when the session ends.

[0045] 2. When a temporary user logs out from the foreground or is explicitly logged out, the system will automatically remove the user from the user list and trigger a series of cleanup steps in the background without requiring manual intervention from the device administrator.

[0046] 3. Delete all application private data (application data directories, databases, SharedPreferences, etc.) under this user account. SharedPreferences is a persistent storage mechanism in the Android system based on key-value pairs, stored in XML files, and used to save application configuration and lightweight state data.

[0047] 4. Uninstall or undo application data or user-wide package data that was installed specifically for this user.

[0048] 5. Release system resources associated with the user (such as processes, bound services, memory mappings, temporary permissions, etc.).

[0049] However, data from other types of background users besides GUEST users still consumes system space. Real-world systems contain a large number of non-GUEST background user types (such as regular secondary users, managed / working profiles, demo users, manufacturer-specified auxiliary users, test accounts, etc.). When these users exit the foreground or become inactive, the data and files they generate are not automatically reclaimed by the system, leading to long-term storage consumption issues.

[0050] The above user types are explained as follows:

[0051] Secondary users: Standard user accounts manually created by the device owner, often used for family sharing or different driver profiles. Their application-private data, cached and downloaded content are usually retained on the device.

[0052] Managed profile / Work profile: A workspace in an enterprise management scenario, where data, policy configurations, certificates, and applications occupy independent storage space.

[0053] Demo users: Demo accounts used for showroom or testing are often recreated, but if not treated as temporary users, they can occupy space for a long time.

[0054] Pre-installed users created by the system or OEM: Some manufacturers or integrators create additional users at the factory for testing or customization; if not cleaned up, this junk data will accumulate over the device's lifecycle.

[0055] The types of data involved include:

[0056] Application private directories (such as / data / user / ) <userid> / <package>Application cache, SQLite database, SharedPreferences, downloaded media or temporary files, files written by the application to external / shared storage, and system databases and indexes associated with the user (such as user configuration tables, account credentials, certificates, logs, etc.).

[0057] For most cockpit use cases, such as car sharing, multi-screen multi-user scenarios, and auto shows, a large number of users will be created. The system will create a separate data directory for each user (e.g., / data / user / ).<user_id> (etc.) to ensure that user data is isolated from each other; as the number of applications and the amount of data increase, the ROM space occupied by this part will increase more and more; and in the above scenario, some users will remain in an inactive state for a long time after switching to the background. The user data of these inactive users will waste a lot of system storage space, especially for mid-to-low-end models with limited ROM space, which has a greater impact.

[0058] To address this, this application adds an Android system service that uses task scheduling to periodically check user login status and clean up data from inactive users, thereby saving cockpit ROM space.

[0059] 1. Under certain conditions, compress and store the data of inactive users while retaining the login entry point. The data will be decompressed when the user logs in.

[0060] 2. When certain conditions are met, notify the administrator to remove inactive users via notification.

[0061] See Figure 2 The solution architecture diagram and related explanations are as follows:

[0062] 1. Application layer: Add a "Periodicly clean up inactive user data" function switch to the "Multi-user Management" interface in the Setting application for users to choose;

[0063] 2. Framework Java layer: Add a system service UserDataHibernationService, which runs in the systemserver process and provides interfaces for data directory compression and decompression; at the same time, implement an inner class JobService to periodically check whether any users meet the freezing or removal conditions;

[0064] 3. Framework Native Layer: The installd process, which has root privileges, is responsible for the specific file operations.

[0065] The core functions of UserDataHibernationService include... Figure 3 As shown, after a user enables the "Periodic Cleanup of Inactive User Data" function in the "Multi-User Management" interface of the Setting application, the system service UserDataHibernationService will periodically check whether any users meet the conditions for freezing or removing them. For example, if a user is found to have not logged in for more than A days, a compression operation will be triggered; if a user is found to have not logged in for more than B days, the administrator will be notified to delete the user via Notification.

[0066] In specific implementation, step S1 includes:

[0067] S11. Configure the determination condition to determine whether the user's unlogin duration exceeds a preset threshold.

[0068] Specifically, determining whether a user's inactivity time exceeds a preset threshold includes:

[0069] Obtain the last activity timestamp of each user stored in the in-vehicle infotainment system; calculate the time difference between the current system time and the last activity timestamp to determine whether it exceeds a preset threshold.

[0070] S12. If the user is inactive for more than the first threshold time, freeze the user data, perform compression and storage operations on the user data, and retain the user login entry.

[0071] S13. If the user is in an inactive state for more than a second threshold, then remove the user data, wherein the second threshold is greater than the first threshold.

[0072] It is worth noting that the size of the first threshold and the second threshold can be dynamically set according to the size and remaining status of the ROM, and this embodiment does not impose any restrictions on this.

[0073] S2. The background service periodically monitors the activity status of each user at preset time intervals, and identifies target users who meet the data cleaning conditions based on the judgment criteria.

[0074] Furthermore, in step S2, when a decrease in vehicle usage frequency is detected, the preset time interval for monitoring is shortened; when an increase in vehicle usage frequency is detected, the preset time interval is extended. This allows for better adaptation to changes in demand.

[0075] S3. Perform a data cleanup operation on the target user corresponding to the determination condition to release storage space.

[0076] This solves the problem of wasted ROM space in multi-user scenarios for the Android operating system in IVI.

[0077] It is understandable that this application addresses the multi-user management and storage reclamation issues in Android, combining strategic user lifecycle management with a low-overhead background reclamation mechanism, which can bring the following beneficial effects to in-vehicle cockpits and other devices with limited ROM:

[0078] 1. Significantly saves storage space and extends usable capacity.

[0079] By implementing configurable automatic recycling policies for various types of background users (not limited to Guest), this application can reclaim user private data, cache, and temporary files by compression or removal when a user becomes inactive or meets the recycling conditions, thereby reducing the accumulation of long-term useless data.

[0080] 2. Improve the success rate of system updates and OTA (Over-The-Air) updates.

[0081] By reclaiming redundant data, the system can maintain a higher available free space, reducing the risk of OTA download failures, installation failures, or rollbacks due to insufficient space. This is especially important for in-vehicle infotainment systems with strict update windows, as it can reduce human intervention and service interruptions caused by upgrade failures.

[0082] 3. Enhance privacy protection and security

[0083] Automated user data recycling reduces the amount of sensitive information (such as location data, call logs, photos, etc.) that is retained long-term, lowering the risk of data leakage on the device owner's or enterprise's equipment. It can be combined with automatic revocation of credentials / certificates to ensure that expired user credentials do not remain indefinitely.

[0084] In summary, this application configures an inactive user data cleanup strategy, which defines the conditions for determining a user's activity status and at least one data cleanup operation corresponding to the conditions. The background service periodically monitors the activity status of each user at preset time intervals, identifies target users that meet the data cleanup conditions based on the conditions, and performs data cleanup operations corresponding to the conditions on the target users to release storage space.

[0085] Therefore, the inactive user data management method described in this application can effectively solve the problem of system resource shortage caused by limited ROM space in in-vehicle infotainment systems. By intelligently identifying and automatically cleaning up inactive user data in multi-user scenarios, it significantly releases storage space and ensures that the system always maintains sufficient available capacity to support critical functions. In particular, by periodically monitoring user activity and performing targeted data cleaning operations, this method not only reduces the risk of OTA update failures caused by insufficient storage space and improves the success rate of vehicle software upgrades, but also reduces the amount of long-term retained sensitive user information, enhancing the data security and privacy protection capabilities of the in-vehicle system. For mid-to-low-end vehicles with limited ROM resources, it can extend the system's lifespan and improve the user experience without increasing hardware costs.

[0086] Secondly, embodiments of this application also provide an inactive user data management device.

[0087] In one embodiment, reference is made to Figure 4 , Figure 4 This is a schematic diagram of the functional modules of an embodiment of the inactive user data management device of this application. Figure 4 As shown, the inactive user data management device includes:

[0088] A configuration module is used to configure a data cleanup strategy for inactive users. The data cleanup strategy defines the conditions for determining the user's activity status and at least one data cleanup operation corresponding to the conditions.

[0089] The monitoring module is used to periodically monitor the activity status of each user through a background service at preset time intervals, and identify target users who meet the data cleaning conditions based on the judgment conditions.

[0090] The execution module is used to perform data cleanup operations on the target user corresponding to the judgment conditions in order to release storage space.

[0091] Furthermore, in one embodiment, the configuration module configures an inactive user data cleanup strategy. The data cleanup strategy defines conditions for determining a user's activity level and at least one data cleanup operation corresponding to those conditions, including:

[0092] The determination condition is configured to determine whether the user's inactivity time exceeds a preset threshold;

[0093] If a user remains inactive for more than the first threshold, the user data will be frozen, compressed, and stored, while the user login entry will be retained.

[0094] If a user remains inactive for more than a second threshold, the user data is removed, where the second threshold is greater than the first threshold.

[0095] Furthermore, in one embodiment, the monitoring module determines whether the user's inactivity time exceeds a preset threshold, including:

[0096] Obtain the last activity timestamp of each user stored in the in-vehicle infotainment system;

[0097] Calculate the time difference between the current system time and the last activity timestamp to determine whether it exceeds a preset threshold.

[0098] Furthermore, in one embodiment, the execution module removing user data includes removing at least one of user private data, cache, and temporary files.

[0099] Furthermore, in one embodiment, the monitoring module periodically monitors the activity status of each user through a background service at preset time intervals, and identifies target users who meet the data cleanup conditions based on the judgment criteria, including:

[0100] A user data hibernation service runs in the systemserver process, and provides interfaces for data directory compression and decompression;

[0101] Implement an inner class of JobService to periodically check if any users meet the freeze or removal conditions.

[0102] Furthermore, in one embodiment, the monitoring module is also used for:

[0103] When a decrease in vehicle usage frequency is detected, the preset time interval for monitoring is shortened; when an increase in vehicle usage frequency is detected, the preset time interval is extended.

[0104] Furthermore, in one embodiment, the target users include secondary users, demo users, pre-configured auxiliary users, and / or test accounts.

[0105] The functions of each module in the aforementioned inactive user data management device correspond to the steps in the aforementioned inactive user data management method embodiment, and their functions and implementation processes will not be described in detail here.

[0106] Thirdly, embodiments of this application provide an inactive user data management device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0107] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of the inactive user data management device involved in the embodiments of this application. In the embodiments of this application, the inactive user data management device may include a processor, a memory, a communication interface, and a communication bus.

[0108] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0109] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within inactive user data management devices, as well as interfaces used for interconnecting inactive user data management devices with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0110] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0111] The processor can be a general-purpose processor, which can call the inactive user data management program stored in memory and execute the inactive user data management method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the inactive user data management program is called can be referred to in the various embodiments of the inactive user data management method of this application, and will not be repeated here.

[0112] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0113] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0114] The present application provides a computer-readable storage medium storing an inactive user data management program, wherein when the inactive user data management program is executed by a processor, it implements the steps of the inactive user data management method described above.

[0115] The method implemented when the inactive user data management program is executed can be referred to in various embodiments of the inactive user data management method of this application, and will not be repeated here.

[0116] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0117] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0118] In the description of the embodiments in this application, terms such as "exemplary," "for example," or "for instance" are used to indicate that they are examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being better or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0119] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0120] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0122] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.< / package> < / userid>

Claims

1. A method for managing inactive user data, applied to an in-vehicle infotainment system, wherein the in-vehicle infotainment system is an Android multi-user system, and the Android multi-user system is used to create an independent data directory for each user, the data directory including / data / user / <user_id> Its characteristics are, The method for managing inactive user data includes: Configure an inactive user data cleanup strategy, wherein the data cleanup strategy defines the conditions for determining the user's activity status and at least one data cleanup operation corresponding to the conditions; The background service periodically monitors the activity status of each user at preset time intervals, and identifies target users who meet the data cleaning conditions based on the judgment criteria. Perform a data cleanup operation on the target user corresponding to the determination condition to free up ROM storage space; The configuration of the inactive user data cleanup strategy defines the conditions for determining user activity status and at least one data cleanup operation corresponding to the conditions, including: The determination condition is configured to determine whether the user's inactivity time exceeds a preset threshold; If a user remains inactive for more than the first threshold, the user data will be frozen, compressed, and stored, while the user login entry will be retained. If a user remains inactive for more than a second threshold, the user data is removed, wherein the second threshold is greater than the first threshold, and the user data includes the data directory.

2. The method for managing inactive user data as described in claim 1, characterized in that, The determination of whether the user's inactivity time exceeds a preset threshold includes: Obtain the last activity timestamp of each user stored in the in-vehicle infotainment system; Calculate the time difference between the current system time and the last activity timestamp to determine whether it exceeds a preset threshold.

3. The method for managing inactive user data as described in claim 1, characterized in that: The removal of user data also includes removing at least one of the cache and temporary files.

4. The method for managing inactive user data as described in claim 1, characterized in that, The process of periodically monitoring the activity status of each user through a background service at preset time intervals, and identifying target users who meet the data cleanup conditions based on the judgment criteria, includes: A user data hibernation service runs in the systemserver process, and provides interfaces for data directory compression and decompression; Implement an inner class of JobService to periodically check if any users meet the freeze or removal conditions.

5. The method for managing inactive user data as described in claim 1, characterized in that, Also includes: When a decrease in vehicle usage frequency is detected, the preset time interval for monitoring is shortened; when an increase in vehicle usage frequency is detected, the preset time interval is extended.

6. The method for managing inactive user data as described in claim 1, characterized in that: The target users include secondary users, demo users, pre-installed auxiliary users, and / or test accounts.

7. An inactive user data management device, applied to an in-vehicle infotainment system, wherein the in-vehicle infotainment system is an Android multi-user system, the Android multi-user system being used to create an independent data directory for each user, the data directory including / data / user / <user_id> Its characteristics are, The inactive user data management device includes: A configuration module is used to configure a data cleanup strategy for inactive users. The data cleanup strategy defines the conditions for determining the user's activity status and at least one data cleanup operation corresponding to the conditions. The monitoring module is used to periodically monitor the activity status of each user through a background service at preset time intervals, and identify target users who meet the data cleaning conditions based on the judgment conditions. An execution module is used to perform data cleanup operations on the target user corresponding to the judgment conditions in order to free up storage space; The configuration module configures a data cleanup strategy for inactive users. The data cleanup strategy defines the criteria for determining a user's activity level and at least one data cleanup operation corresponding to those criteria, including: The determination condition is configured to determine whether the user's inactivity time exceeds a preset threshold; If a user remains inactive for more than the first threshold, the user data will be frozen, compressed, and stored, while the user login entry will be retained. If a user remains inactive for more than a second threshold, the user data is removed, wherein the second threshold is greater than the first threshold, and the user data includes the data directory.

8. A device for managing inactive user data, characterized in that, The inactive user data management device includes a processor, a memory, and an inactive user data management program stored in the memory and executable by the processor, wherein when the inactive user data management program is executed by the processor, it implements the steps of the inactive user data management method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an inactive user data management program, wherein when the inactive user data management program is executed by a processor, it implements the steps of the inactive user data management method as described in any one of claims 1 to 6.

Images