Resource scheduling method based on vehicle-mounted android device aging test and related device

Abstract

The application discloses a resource scheduling method based on vehicle-mounted Android device aging test and related devices, and the method comprises the following steps: when the aging test of a target vehicle-mounted Android device is performed, the initial resource idle quantity corresponding to the vehicle-mounted Android device operating system is acquired first, then the n to-be-executed tasks corresponding to the vehicle-mounted Android device and the n resource demand quantities corresponding to the n to-be-executed tasks are determined, then the priority of each to-be-executed task in the n to-be-executed tasks is determined to obtain n priorities, and finally, the k target to-be-executed tasks in the n to-be-executed tasks are determined based on the initial resource idle quantity, the n resource demand quantities and the n priorities, so that the vehicle-mounted Android device operating system executes the k target to-be-executed tasks, and the idle resource utilization efficiency of the vehicle-mounted Android device operating system is improved under the premise that the aging test of the vehicle-mounted Android device is normally performed.

Description

Technical Field

[0001] This invention relates to the field of aging test technology for in-vehicle Android devices, and in particular to a resource scheduling method and related apparatus based on aging test of in-vehicle Android devices. Background Technology

[0002] With the rapid development of in-vehicle intelligent devices, in-vehicle terminals based on the Android system have become the core components of automotive intelligence. To ensure that in-vehicle Android devices can operate stably for a long time under complex working conditions, they must undergo rigorous aging tests before leaving the factory. The hardware reliability and system stability are verified by continuous pressurized operation.

[0003] In the existing testing process, when performing aging tests on in-vehicle Android devices, the devices typically run aging test tasks independently without effectively utilizing the idle system resources generated during the aging test. This results in these idle resources remaining idle for a long time, causing significant resource waste. Therefore, how to improve the utilization efficiency of idle resources in the operating system of in-vehicle Android devices while ensuring the normal execution of aging tests has become an urgent problem to be solved in the current aging test process of in-vehicle Android devices. Summary of the Invention

[0004] This application provides a resource scheduling method and related apparatus based on aging tests of in-vehicle Android devices, which improves the utilization efficiency of idle resources of the in-vehicle Android device operating system while ensuring the normal execution of aging tests.

[0005] In a first aspect, embodiments of this application provide a resource scheduling method based on aging tests of in-vehicle Android devices, applied to an in-vehicle Android device operating system, the method comprising: When performing an aging test on the target in-vehicle Android device, obtain the initial amount of free resources corresponding to the operating system of the in-vehicle Android device; Determine n tasks to be executed corresponding to the in-vehicle Android device, and n resource requirements corresponding to the n tasks to be executed; each task to be executed corresponds to one resource requirement; Determine the priority of each of the n tasks to be executed, thus obtaining n priorities; Based on the initial amount of available resources, the n resource requirements, and the n priorities, k target tasks are determined from the n tasks to be executed, so that the in-vehicle Android device operating system executes the k target tasks to be executed; k is an integer less than or equal to n.

[0006] Secondly, this application provides a resource scheduling device based on aging test of in-vehicle Android device, applied to in-vehicle Android device operating system, the device comprising: an acquisition unit and a processing unit; The acquisition unit is used to acquire the initial free resource amount corresponding to the operating system of the vehicle Android device when performing an aging test on the target vehicle Android device. The processing unit is used to determine n tasks to be executed corresponding to the in-vehicle Android device, and n resource requirements corresponding to the n tasks to be executed; each task to be executed corresponds to one resource requirement. Determine the priority of each of the n tasks to be executed, thus obtaining n priorities; Based on the initial available resources, the n resource requirements, and the n priorities, k target tasks are determined from the n tasks to be executed, so that the in-vehicle Android device operating system can perform the execution operation on the k target tasks to be executed; k is an integer less than or equal to n.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including: a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor to cause the electronic device to perform the method as described in the first aspect.

[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method as described in the first aspect.

[0009] Fifthly, embodiments of the present invention provide a computer program product including a non-transitory computer-readable storage medium storing a computer program, such that a computer performs the method as described in the first aspect.

[0010] Implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the resource scheduling method based on aging test of in-vehicle Android devices described in this embodiment of the invention is applied to the operating system of an in-vehicle Android device. When performing aging test on a target in-vehicle Android device, the initial idle resource amount corresponding to the in-vehicle Android device operating system is first obtained. Then, n tasks to be executed corresponding to the in-vehicle Android device and n resource requirements corresponding to the n tasks to be executed are determined. Next, the priority of each of the n tasks to be executed is determined to obtain n priorities. Finally, based on the initial idle resource amount, the n resource requirements, and the n priorities, k target tasks to be executed from the n tasks to be executed are determined, so that the in-vehicle Android device operating system executes the k target tasks to be executed. Under the premise of ensuring the normal execution of the aging test of the in-vehicle Android device, the idle resource utilization efficiency of the in-vehicle Android device operating system is improved. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0012] Figure 1 This is a flowchart of a resource scheduling method based on aging test of an in-vehicle Android device provided in an embodiment of this application; Figure 2 This is a flowchart for determining n priorities provided in an embodiment of this application; Figure 3 This is a flowchart provided in an embodiment of the present application for determining the urgency value corresponding to a first task to be executed; Figure 4 This is a flowchart illustrating another method for determining the urgency value of a first task to be executed, provided in an embodiment of this application. Figure 5 This is a flowchart of determining k target tasks to be executed, provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an in-vehicle Android device operating system provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a resource scheduling device based on aging test of an in-vehicle Android device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] 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 a part of the embodiments of the present application, and not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application.

[0014] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, 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 these processes, methods, products, or apparatuses.

[0015] In this document, the term "implementation" means that a specific feature, structure, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0016] Please see Figure 1 , Figure 1 This is a flowchart illustrating a resource scheduling method based on aging tests of in-vehicle Android devices, provided in an embodiment of this application. The resource scheduling method based on aging tests of in-vehicle Android devices is applied to the operating system of an in-vehicle Android device, and the method includes, but is not limited to, the following steps: S101: When performing an aging test on the target vehicle Android device, obtain the initial amount of free resources corresponding to the operating system of the vehicle Android device.

[0017] In this embodiment, the in-vehicle Android device operating system can be an embedded operating system deeply customized for the in-vehicle scenario based on the Android system, mainly running on in-vehicle hardware devices such as the vehicle's central control screen and smart cockpit. While retaining the core capabilities of the original Android system, such as application management, multitasking, and process scheduling, the in-vehicle Android device operating system adapts to the specific hardware environment and functional requirements of vehicles. It integrates vehicle-related drivers, system services, and communication protocols, and is responsible for the unified management and scheduling of the in-vehicle device's computing core, RAM, storage space, display module, audio equipment, network, and vehicle-machine interface, as well as providing a runtime environment for various in-vehicle applications such as navigation, multimedia playback, Bluetooth connectivity, vehicle settings, and voice control. During aging tests, the in-vehicle Android device operating system, as the core operating platform, plays a crucial role in statistically analyzing resource idle status, loading test tasks, executing task scheduling, and ensuring stable system operation.

[0018] In this embodiment, the in-vehicle Android device refers to vehicle smart hardware equipped with a vehicle-specific operating system based on Android. It is usually integrated inside the vehicle and exists in the form of a central control screen, vehicle host, smart cockpit, etc. It can realize a variety of in-vehicle functions such as navigation, audio and video entertainment, vehicle settings, Bluetooth connection, voice interaction and vehicle networking. At the same time, it is compatible with various hardware and sensors of the vehicle and operates stably during vehicle driving and use. It is also the specific hardware carrier for carrying out aging tests, resource scheduling and other related operations.

[0019] In this embodiment, the aging test of the in-vehicle Android device is to allow the in-vehicle Android device to run various functions and tasks continuously for a long time in an environment that is close to or even more intense than real use before the vehicle intelligent device is officially put into use or mass production. This simulates the working state of the device during long-term use and examines whether the system is stable, whether the hardware is reliable, whether the resource scheduling is reasonable, and whether there are problems such as lag, crashes, functional abnormalities, or performance degradation under continuous high load operation. This allows for the early detection of potential defects in the device during long-term use and ensures the safety and stability of the in-vehicle device in actual use.

[0020] When conducting aging tests on target automotive Android devices, it's crucial to first determine the initial available resources for the device's operating system. This is because aging tests typically require the device to run under continuous, high load. The total amount of available computing, memory, and storage resources in the automotive Android device's operating system directly determines how many test tasks can be launched simultaneously and how much operational pressure can be applied. Obtaining the initial available resources in advance prevents blindly loading tasks due to a lack of understanding of the available resources, which could lead to device overload, lag, crashes, or even test failures. It also ensures that the entire aging test process is conducted within a controllable and stable resource range, resulting in more realistic and reliable test results.

[0021] It should be explained that the initial amount of free resources corresponding to the in-vehicle Android device operating system can specifically include at least one or more of the following resources: CPU utilization, RAM usage, and storage bandwidth usage.

[0022] S102: Determine the n tasks to be executed corresponding to the in-vehicle Android device, and the n resource requirements corresponding to the n tasks to be executed.

[0023] In this embodiment, each task to be executed corresponds to a resource requirement. The in-vehicle Android device mainly includes tasks such as continuous navigation positioning and map rendering, high-definition audio and video loop playback, Bluetooth device connection and data transmission, multi-touch simulation of the vehicle screen, repeated switching of vehicle setting parameters, continuous interaction with the voice assistant, batch installation and uninstallation of background applications, continuous reading and processing of sensor data, uploading and downloading of vehicle network data, and simultaneous switching of multiple applications. Each of these is an independent task to be executed, and each task will consume computing, memory, storage, and other resources of the in-vehicle Android device's operating system during operation. Therefore, each task to be executed corresponds to a specific resource requirement.

[0024] The continuous navigation positioning and map rendering task refers to continuously running a navigation application on an in-vehicle Android device, constantly acquiring vehicle location information, and loading, drawing, and refreshing the map in real time. This simulates a scenario where navigation is running continuously while the vehicle is in motion, thus testing the operational stability of the in-vehicle Android device during continuous positioning and graphics rendering. The resource requirements for this task are mainly reflected in high CPU usage and large RAM consumption of the in-vehicle Android device's operating system. It also requires continuous access to positioning modules and graphics processing hardware resources, resulting in continuous consumption of display resources.

[0025] The high-definition audio and video loop playback task is to make the in-vehicle Android device continuously play high-definition music or video files, constantly calling audio decoding, video decoding, speaker output, and screen display functions. This simulates prolonged use of multimedia entertainment functions by the user and detects whether the in-vehicle Android device experiences stuttering, silence, screen flickering, or abnormal overheating during continuous multimedia operation. The resource requirements for this task mainly include high CPU core usage, a certain amount of RAM usage, and continuous audio and video decoding resource consumption, while also consuming storage read and display output resources.

[0026] The Bluetooth device connection and data transmission task simulates the process of repeatedly establishing connections and transmitting music, call data, or file data between an in-vehicle Android device and Bluetooth devices such as mobile phones and headphones. Through continuous Bluetooth connection and data interaction, it tests the stability of the Bluetooth module of the in-vehicle Android device and the scheduling ability of the in-vehicle Android device's operating system for Bluetooth-related resources. The resource requirements for the Bluetooth device connection and data transmission task are mainly moderate core usage and small memory usage, while continuously occupying Bluetooth communication module resources and data transmission-related bandwidth resources.

[0027] Multi-touch simulation tasks on in-vehicle infotainment screens involve simulating continuous and frequent multi-touch operations, such as swiping, clicking, and zooming, on the central control screen of an in-vehicle Android device, either programmatically or manually. This simulates scenarios where users frequently operate the infotainment system while driving, testing the touch response speed, recognition accuracy, and whether the device malfunctions or experiences delays under prolonged touch. The resource requirements for multi-touch simulation tasks on in-vehicle infotainment screens are primarily low in processing cores and a small amount of RAM, mainly consuming touch driver resources and interface rendering-related resources.

[0028] The task of repeatedly switching vehicle settings parameters involves continuously switching vehicle-related settings options on the in-vehicle Android device, such as brightness adjustment, volume adjustment, air conditioning control mode switching, driving mode switching, and display theme switching. By frequently modifying and applying these settings, the task tests whether the in-vehicle Android device's operating system experiences settings failures, interface freezes, or functional abnormalities when configurations are frequently changed. The resource requirements for this task are mainly low CPU core usage and a small amount of RAM usage, primarily consuming resources related to configuration read / write operations and interface refresh.

[0029] The continuous interaction task for the voice assistant involves continuously issuing voice commands to the in-vehicle Android device, causing the voice assistant to constantly perform wake-up, recognition, semantic understanding, and command execution operations. This simulates a scenario of prolonged continuous voice control use, testing the long-term reliability of the in-vehicle Android device in terms of audio acquisition, voice processing, and response execution. The resource requirements for the continuous interaction task for the voice assistant are mainly moderate in terms of computing core usage and RAM usage, while continuously consuming resources related to audio acquisition and voice algorithm processing.

[0030] The background application batch installation and uninstallation task involves repeatedly installing and uninstalling applications on in-vehicle Android devices. It continuously reads and writes storage space and calls installation and uninstallation services to test whether storage anomalies, installation failures, or system lag occur under frequent storage read / write operations and changes in the operating environment. The resource requirements for this task are primarily high storage read / write resource usage, medium processing core usage, and a certain amount of RAM usage.

[0031] The continuous sensor data reading and processing task involves the in-vehicle Android device continuously reading various sensor data from the vehicle, including vehicle speed, RPM, fuel level, temperature, door status, and radar information. This data is then parsed, displayed, and logically processed to test the accuracy and operational stability of the in-vehicle Android device during continuous data reception and processing. The resource requirements for this task are primarily medium-level processing core usage, a small amount of RAM usage, and continuous consumption of vehicle bus communication resources and sensor data parsing-related resources.

[0032] The vehicle-to-everything (V2X) data upload and download task involves continuously uploading and downloading cloud data to in-vehicle Android devices via mobile networks. This includes tasks such as real-time traffic updates, remote vehicle status queries, log reporting, and online map updates. It simulates long-term data interaction in a connected vehicle environment, testing the connection stability and resource consumption of in-vehicle Android devices during continuous network transmission. The resource requirements for this V2X data upload and download task primarily involve medium-level computing core usage, a small amount of RAM usage, and also network communication bandwidth and data caching resources.

[0033] Simultaneous switching of multiple applications to run pending tasks involves opening multiple applications such as navigation, music, Bluetooth, and vehicle settings on an in-vehicle Android device, and continuously switching between these applications in the foreground. This simulates a real-world user scenario where users frequently switch between functions while driving, testing the resource scheduling capabilities and operational smoothness of the in-vehicle Android device's operating system under concurrent application operation and frequent switching. The resource requirements for simultaneously switching multiple applications to run pending tasks mainly include high CPU core usage, large RAM usage, and the consumption of background resources for multiple applications and rendering resources for rapid interface switching.

[0034] S103: Determine the priority of each of the n tasks to be executed, and obtain n priorities.

[0035] In this embodiment, task attribute data related to the n tasks to be executed can be obtained first. This task attribute data may include information such as the functional importance of the tasks to be executed, the degree of impact on driving safety, resource consumption characteristics, and test target emphasis. Then, based on these task attribute data, the corresponding urgency values ​​are calculated and determined for each of the n tasks to be executed, thereby obtaining n urgency values. Finally, the corresponding n priorities are determined according to the size of the urgency values, wherein the larger the urgency value of the task to be executed, the higher the priority of the task to be executed, thereby determining the n priorities corresponding to the n tasks to be executed.

[0036] S104: Based on the initial amount of available resources, the n resource requirements, and the n priorities, determine k target tasks to be executed from the n tasks to be executed, so that the vehicle-mounted Android device operating system executes the k target tasks to be executed.

[0037] In this implementation, k is an integer less than or equal to n. All tasks to be executed can be arranged in descending order of priority. Then, starting with the highest priority task, each task is evaluated sequentially. When evaluating the highest priority task, the currently available resources are the initial available resources. The resource requirement of the task is checked against the currently available resources. If the resource requirement exceeds the available resources, the task is skipped, and the available resources remain unchanged. The process continues with the next priority task. If the resource requirement is less than or equal to the available resources, the task is designated as a target task. The current available resources are subtracted from the current available resources to obtain a new set of available resources, which is used for evaluating the next task. This process is repeated for all n tasks. The final selection of all tasks meeting the criteria constitutes the k target tasks to be executed.

[0038] As can be seen, resource scheduling based on the aging test of in-vehicle Android devices can accurately determine the initial idle resources of the in-vehicle Android device operating system before the aging test begins. Then, by combining the resource requirements and priorities of each task to be executed, reasonable selection can be made. This ensures that higher-priority and more important tasks are executed first, ensuring that the aging test can focus on verifying the core functions and key performance of the in-vehicle Android device. At the same time, it can reasonably select k target tasks to be executed based on the actual available resources, avoiding problems such as overload, lag, and crashes in the in-vehicle Android device operating system due to insufficient resources. This makes the entire aging test process more stable and controllable, improves test efficiency and the reliability of test results, and maximizes the completion of effective aging test tasks with limited resources.

[0039] It should be explained that, in this embodiment, after the target vehicle-mounted Android device enters the aging test mode, the vehicle-mounted Android device operating system can first complete system initialization, start parallel task execution related functions, and load a task queue to be executed, including hardware self-test, vehicle software copying, system configuration updates, application pre-installation, etc. Subsequently, the vehicle-mounted Android device operating system performs aging tests on the target vehicle-mounted Android device, and simultaneously starts resource monitoring related functions to collect system operation information such as CPU usage, RAM usage, storage read / write load, and target vehicle-mounted Android device temperature in real time. The vehicle-mounted Android device operating system monitors the system according to preset resource safety thresholds. The system uses control information to determine whether to start a task. When system resources are available, the corresponding task is selected from the task queue and started. When system resources are scarce, the target vehicle Android device is too hot, or the smoothness of the aging test decreases, the parallel tasks are immediately paused or stopped. The tasks are scheduled to resume execution after the system resources are available again. This process is repeated until the aging test is completed. Finally, the vehicle Android device operating system checks the completion status of all tasks and generates a task execution report. Under the premise of ensuring the stable completion of the aging test, the system makes full use of the idle resources of the target vehicle Android device to complete multiple production processes simultaneously, thus shortening the overall production time. The various functional modules within the in-vehicle Android device operating system can work collaboratively. The resource monitoring module continuously collects operational status information such as CPU usage, RAM usage, storage read / write load, target in-vehicle Android device temperature, and aging test execution smoothness, and transmits this information in real time to the task scheduling module. Based on the acquired status information, combined with the priority of the tasks to be executed and resource safety conditions, the task scheduling module sequentially sends control commands to the task queue, the hardware components of the target in-vehicle Android device, and the aging test process. When system resources are sufficient, it issues a task start command; when system resources are insufficient or the target in-vehicle Android device is malfunctioning, it issues a pause or stop command. At the same time, it always ensures that the aging test has the highest execution privileges and a stable resource supply. The various functional modules respond sequentially and cooperate with each other, enabling the in-vehicle Android device operating system to run the tasks to be executed stably, safely, and efficiently while performing the aging test. This achieves the synchronous advancement of aging test and production processes, improving the automation level and overall efficiency of the production process.

[0040] Please see Figure 2 , Figure 2 This application provides a flowchart for determining n priorities, including but not limited to the following steps: S201: Obtain the task attribute data corresponding to the in-vehicle Android device.

[0041] In this embodiment, the task attribute data corresponding to the in-vehicle Android device may include various feature information related to the task to be executed, specifically including the function type of the task to be executed itself, the hardware module information that it depends on and calls during runtime, the test purpose and importance of the task to be executed in the aging test, the type and scale of the occupation of in-vehicle hardware resources during the execution of the task to be executed, the relationship between the task to be executed and the hardware modules covered by the aging test of the in-vehicle Android device, the degree of mutual influence between the task to be executed and the aging test when using the same hardware resources, the specific hardware component information detected by the hardware self-test type task to be executed, and the resource competition and cooperation relationship between the task to be executed and other test processes.

[0042] S202: Based on the task attribute data, determine the urgency value corresponding to each of the n tasks to be executed, and obtain n urgency values.

[0043] In this embodiment, for each task to be executed, key feature information related to the task to be executed is first extracted from the task attribute data, such as functional importance, degree of correlation with driving safety, impact on equipment stability, resource consumption, whether it is a core test item, degree of correlation of hardware modules, and degree of resource coupling. Then, based on these data, n urgency values ​​corresponding to the n tasks to be executed are determined according to preset calculation logic or mapping relationship.

[0044] S203: Determine the n priorities based on the n urgency values.

[0045] In this embodiment, the higher the urgency value of the task to be executed, the higher the priority of the task to be executed.

[0046] After obtaining the urgency values ​​of each of the n tasks to be executed, we can directly sort and compare these urgency values ​​according to their magnitude. Based on preset rules, we can associate the urgency values ​​with priority levels. The higher the urgency value of a task, the more important it is in the aging test and the more priority it needs to be scheduled for execution. Therefore, we assign it a higher priority. The lower the urgency value, the lower the corresponding priority. Finally, we determine the priority corresponding to each task to be executed, thus obtaining a complete set of n priorities.

[0047] As can be seen, by first obtaining the task attribute data corresponding to the in-vehicle Android device, the calculation of the urgency value has an objective and realistic basis, avoiding the bias caused by human subjective judgment. Then, based on the task attribute data, the corresponding urgency value for each task to be executed can be calculated, which can quantitatively distinguish the importance of each task to be executed. Finally, the priority is determined according to the rule that the higher the urgency value, the higher the priority. This can ensure that in the aging test of the in-vehicle Android device, the more important, more critical, and more influential tasks on the stability of the device and the test results are given priority. This not only makes resource scheduling more reasonable, but also ensures that the key contents of the aging test are executed first, improving the effectiveness and reliability of the test.

[0048] When the first task to be executed is a hardware self-test, the first task to be executed is one of the n tasks to be executed. Please refer to [link / reference]. Figure 3 , Figure 3 This application provides a flowchart for determining the urgency value of a first task to be executed, including but not limited to the following steps: S301: Based on the task attribute data, determine the overlap and resource coupling degree of the hardware modules corresponding to the execution of the first task to be executed and the aging test.

[0049] In this embodiment, the hardware module information that the first task to be executed, hardware self-test, depends on and is tested, as well as the hardware module information that needs to be called and stressed during the aging test of the vehicle Android device, can be extracted from the task attribute data. By comparing the types, models, working channels, and other contents of the hardware modules involved in the two, the proportion and correlation of the same hardware modules can be determined, thereby obtaining the degree of hardware module overlap. At the same time, the usage type, usage sequence, and peak usage of resources such as computing cores, running memory, storage, and communication interfaces of the first task to be executed and the aging test can be extracted from the task attribute data. The analysis can be conducted to determine whether the two compete for, affect, or depend on each other when using resources, thereby determining the degree of resource coupling between the two.

[0050] Determining the degree of overlap and resource coupling of hardware modules corresponding to the execution of the first task to be executed, namely hardware self-test and aging test, can clearly determine the overlap in the use of hardware modules and the degree of mutual influence in resource usage between hardware self-test and aging test. It can identify in advance whether the two will occupy the same hardware at the same time and cause conflicts, and can also accurately assess whether the two will interfere with each other or compete for resources of the vehicle Android device operating system during operation. Therefore, it is necessary to determine the degree of overlap and resource coupling of hardware modules corresponding to the execution of the first task to be executed and the aging test based on the task attribute data.

[0051] In this embodiment, hardware module overlap refers to the degree of similarity and overlap between the hardware modules used and detected by the first task to be executed in the hardware self-test category and the hardware modules that need to be called and pressure tested during the aging test of the vehicle Android device. The higher the overlap, the more identical hardware will be used in the two operations, such as the same screen, the same set of sensors, the same Bluetooth chip, etc. The lower the overlap, the more independent the hardware used by the two operations are and they do not interfere with each other.

[0052] Resource coupling degree refers to the degree to which the first task to be executed in the hardware self-test and the aging test of the vehicle Android device affect, depend on, or compete for resources such as the computing core, running memory, storage bandwidth, power supply allocation, and data bus of the vehicle Android device operating system during operation. The higher the coupling degree, the more likely it is that resource contention, mutual interference, or even instability will occur when the two operations are running simultaneously. The lower the coupling degree, the more independent the resource usage of the two is, and there will be basically no obvious conflict when they are executed at the same time.

[0053] S302: Determine the first urgency value corresponding to the overlap of the hardware module and the second urgency value corresponding to the resource coupling degree.

[0054] In this embodiment, it can be a first mapping relationship between a preset hardware module overlap degree and an urgency value. Based on this first mapping relationship, a first urgency value corresponding to the hardware module overlap degree can be determined.

[0055] It can be a second mapping relationship between a preset resource coupling degree and an urgency value, and a second urgency value corresponding to the resource coupling degree can be determined based on this second mapping relationship.

[0056] S303: Determine the urgency value corresponding to the first task to be executed based on the first urgency value and the second urgency value.

[0057] In this implementation, the urgency value of the first task to be executed can be determined in several ways based on a comprehensive assessment of the first and second urgency values. For example, a weighted summation method can be used, where reasonable weights are assigned to the first urgency value corresponding to the hardware module overlap and the second urgency value corresponding to the resource coupling degree, and then the two values ​​are multiplied by their respective weights and added together to obtain the final urgency value. Alternatively, a weighted average method can be used, where different weights are assigned to the two urgency values, and the weighted result is divided by the sum of the weights to obtain a more balanced comprehensive value. A maximum value method can also be used, where the larger of the first and second urgency values ​​is directly selected as the final urgency value, which is suitable for scenarios where priority needs to be increased if either dimension is high. A summation method can also be used, where the two urgency values ​​are simply added together without setting weights, and the total value reflects the overall urgency. In addition, a multiplicative summation method can be used, where the two urgency values ​​are multiplied, so that the final urgency value is significantly amplified when both values ​​are high, further highlighting the execution urgency in cases of high overlap and high coupling.

[0058] As can be seen, for tasks like hardware self-testing, the overlap of hardware modules and resource coupling between the task and aging tests are first calculated based on the task attribute data. Then, the corresponding first and second urgency values ​​are determined separately. Finally, the two urgency values ​​are combined to obtain the final urgency value of the first task to be executed. This approach can more accurately quantify the importance and urgency of hardware self-testing tasks in a way that is more in line with actual operating scenarios. It fully considers the actual situation of hardware sharing conflicts and resource mutual influences, avoids the irrationality caused by simple uniform scoring, and makes the resulting urgency value more objective and reliable.

[0059] Please see Figure 4 , Figure 4 This is another flowchart provided by an embodiment of the present application for determining the urgency value corresponding to the first task to be executed, including but not limited to the following steps: S401: Determine the first weight corresponding to the first urgency value and the second weight corresponding to the second urgency value.

[0060] In this embodiment, the sum of the first weight and the second weight is 1. The first weight and the second weight can be allocated according to the actual impact of hardware module overlap and resource coupling degree on aging tests. First, the importance of the two is judged in conjunction with the test objectives of the in-vehicle Android device. If hardware module overlap has a greater impact on test stability, a larger first weight is set for the first urgency value. If resource coupling degree is more likely to cause resource preemption or system lag, a larger second weight is assigned to the second urgency value.

[0061] S402: Determine a reference urgency value based on the first urgency value, the second urgency value, the first weight, and the second weight.

[0062] In this embodiment, the reference urgency value can be calculated in the following manner: Reference urgency value = First urgency value × First weight + Second urgency value × Second weight; The reference urgency value can be determined based on the first urgency value, the second urgency value, the first weight, and the second weight in the manner described above.

[0063] S403: Obtain the execution time corresponding to the first task to be executed.

[0064] In this embodiment, since the execution time can directly reflect the running time of the hardware self-test task, the longer the execution time, the longer the task will occupy hardware resources and vehicle Android device operating system resources, and the greater the impact on the overall progress of subsequent aging tests, resource consumption rhythm and task parallel space. Taking the execution time into consideration can make the final determined urgency value more in line with the actual test time and resource consumption. Therefore, it is necessary to obtain the execution time corresponding to the first task to be executed.

[0065] S404: Determine the adjustment parameters corresponding to the execution duration.

[0066] In this embodiment, it can be a mapping relationship between a preset execution duration and adjustment parameters. Based on this mapping relationship, the adjustment parameters corresponding to the execution duration can be determined.

[0067] S405: Adjust the reference urgency value based on the adjustment parameters to obtain the urgency value corresponding to the first task to be executed.

[0068] In this embodiment, the urgency value corresponding to the first task to be executed is calculated in the following manner: The urgency value of the first task to be executed = reference urgency value × (1 + adjustment parameter); The reference urgency value can be adjusted based on the adjustment parameters using the above method to obtain the urgency value corresponding to the first task to be executed.

[0069] It can be seen that by first assigning a first weight and a second weight, with a sum of 1, to the first urgency value corresponding to the hardware module overlap and the second urgency value corresponding to the resource coupling, and calculating the weighted reference urgency value, and then combining the execution time of the first task to be executed to determine the adjustment parameters and correct the reference urgency value, the final urgency value can take into account both the core factors of hardware sharing conflicts and resource mutual influence, and fully consider the impact of the actual task execution time on the test process and resource consumption. This makes the urgency value more accurate, objective, and in line with the real scenario of aging test of in-vehicle Android devices, effectively ensuring the orderly and stable conduct of aging test.

[0070] Please see Figure 5 , Figure 5 This application provides a flowchart for determining k target tasks to be executed, including but not limited to the following steps: S501: According to the n priorities in descending order, determine in turn whether the resource requirement of the task to be executed corresponding to the current priority is less than or equal to the current available resource quantity.

[0071] In this embodiment, when the current priority is the highest priority, the current available resource amount is the initial resource idle amount. First, all n tasks to be executed are sorted from highest to lowest according to the previously determined priority. Then, each task is judged in this order, checking whether the resource requirement of the task currently in the judgment order is less than or equal to the amount of resources currently available to be used by the in-vehicle Android device operating system. At the very beginning of the judgment process, when checking the highest priority task, no task has been selected for execution. Therefore, the current available resource amount used at this time is the initial resource idle amount of the in-vehicle Android device operating system obtained at the start of the aging test.

[0072] S502: If not, skip the task to be executed corresponding to the current priority.

[0073] In this embodiment, the current available resource quantity remains unchanged. When determining the resource requirement of a task to be executed according to priority order, if the resource requirement of the task is greater than the current available resource quantity, the task corresponding to this priority is skipped and not included in the target task range. At the same time, since no resources are allocated to this task, the amount of resources that the in-vehicle Android device operating system can currently allocate will not change, and the original value will continue to be used for resource matching judgment of the next priority task to be executed.

[0074] S503: If so, the task to be executed corresponding to the current priority is determined as the target task to be executed, and the resource requirement of the task to be executed corresponding to the current priority is subtracted from the current available resource quantity to obtain the current available resource quantity corresponding to the next priority, until the n tasks to be executed are traversed to obtain the k target tasks to be executed.

[0075] In this implementation, if, after judgment, the resource requirement of the task to be executed corresponding to the current priority is less than or equal to the current available resources, the task to be executed is determined as the target task to be executed. At the same time, the resource requirement of the task is subtracted from the current available resources, and the remaining resources are used as the current available resources when judging the next low-priority task. Then, the same resource matching judgment is performed on subsequent tasks in descending order of priority until all n tasks to be executed have been traversed and checked. Finally, all tasks that meet the resource requirements are selected, resulting in a total of k target tasks to be executed.

[0076] As can be seen, judging resource sufficiency in descending order of priority and dynamically updating the available resource quantity can ensure that high-priority tasks are selected for execution first in the resource scheduling of aging tests of in-vehicle Android devices, avoiding important tasks from failing to run due to insufficient resources. At the same time, the resource allocation is precisely controlled by dynamically deducting resources to ensure that there is no situation where the available resources are exceeded. This makes the task selection process logically clear and efficient, taking into account the differences in task importance and making full and reasonable use of the initial idle resources of the in-vehicle Android device operating system. The k target tasks to be executed in the end meet the priority requirements and can run stably under the existing resource conditions, improving the overall reliability and orderliness of aging tests.

[0077] It should be explained that during the aging test of the target in-vehicle Android device and the execution of the selected k target tasks, it is also necessary to collect the device temperature and the frame rate of the aging test task in real time. The frame rate of the aging test task can directly reflect the smoothness of the aging test task. When the device temperature exceeds the preset safe temperature threshold, or the frame rate of the aging test task is lower than the preset smooth operation standard, or both abnormal conditions occur at the same time, the execution of all k target tasks will be terminated immediately. By releasing the system resources occupied by these tasks, the device load and heat generation will be reduced, thereby ensuring that the aging test can obtain sufficient operating resources and maintain a stable and normal execution state.

[0078] It's important to explain that during the aging test and the execution of k target tasks, the system continuously monitors the system resource usage of the in-vehicle Android device in real time and presets corresponding resource safety thresholds. When the system resource utilization exceeds these thresholds, the system automatically pauses or stops the k target tasks to ensure that the aging test, as the primary task, always receives sufficient resources, preventing parallel tasks from interfering with the stability and effectiveness of the aging test. After terminating the execution of the k target tasks, if the device temperature drops below the preset temperature and the aging test task execution frame rate recovers to above the preset frame rate, it indicates that the device resources and operating status have returned to normal. At this point, the unfinished portion of the k target tasks can be resumed, maximizing the completion of parallel production tasks while ensuring the stability of the aging test.

[0079] For example, when performing the aging test on the target in-vehicle Android device and the k target tasks to be executed, the device temperature and aging test task execution frame rate of the target in-vehicle Android device are obtained. The aging test task execution frame rate is used to characterize the smoothness of the aging test task execution. Specifically, the device temperature is the real-time temperature value corresponding to the heat generated by the hardware components of the target in-vehicle Android device during the aging test and the k target tasks to be executed. It directly reflects the hardware load and heat dissipation status of the device. Excessive temperature means that the device load is too high and the heat dissipation is insufficient, which may cause hardware throttling, functional abnormalities, or even stability problems. The aging test task execution frame rate is the temperature value of the target in-vehicle Android device during the aging test and the k target tasks to be executed. The number of screen refreshes or processing steps completed per unit time reflects the smoothness of the aging test task. A lower frame rate indicates more sluggish test task execution, suggesting that device resources are being squeezed and processing capacity is insufficient. Acquiring these two data points simultaneously during the aging test and the execution of k target tasks is to monitor the device's operating status and the execution quality of the aging test task in real time, and to promptly detect abnormalities such as device overheating, insufficient resources, and test sluggishness caused by running multiple tasks simultaneously. Therefore, it is necessary to obtain the device temperature and aging test task execution frame rate of the target vehicle Android device when performing the aging test on the target vehicle Android device and the k target tasks.

[0080] For example, if the device temperature is higher than a preset temperature and / or the aging test task execution frame rate is lower than a preset execution frame rate, the execution of the k target tasks to be executed is terminated to ensure the normal execution of the aging test. Specifically, when the device temperature is higher than a preset temperature or the aging test task execution frame rate is lower than a preset execution frame rate, the execution of the k target tasks to be executed is terminated in a timely manner. This can quickly release the in-vehicle Android device operating system resources, hardware resources, and computing power occupied by these tasks, reduce the overall load and heat generation of the device, avoid hardware frequency reduction, functional abnormalities, or device lag due to excessive temperature, and allow more resources to be prioritized for aging test use, ensuring the smooth execution and operational stability of the aging test task, preventing the accuracy of the aging test results from being interfered with by too many concurrent tasks, ensuring that the aging test can be completed continuously under normal and stable conditions, and improving the reliability of test data and the effectiveness of device evaluation.

[0081] It should be explained that the selected k target tasks to be executed are interruptible and fragmentable tasks. Fragmentable tasks can be broken down into multiple independent subtasks and executed in segments when there is an idle window of device resources. Interruptible tasks can be safely paused when system resources are scarce or the device status is abnormal, and the pause process will not affect the correctness of the task execution results, thus ensuring that the priority of aging test is not affected.

[0082] It should be explained that after the aging test is completed, the system will automatically generate a corresponding task execution report. This report records the overall completion status of the k target tasks to be executed, identifies which tasks have been completed during the aging period and which tasks have not been completed, and marks the incomplete tasks so that they can be executed after the aging test is completed.

[0083] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an in-vehicle Android device operating system provided in an embodiment of this application. Figure 6 In the in-vehicle Android device operating system 60, there are in-vehicle Android device 601, in-vehicle device hardware monitoring module 602, in-vehicle task resource scheduling and management module 603, in-vehicle task execution status monitoring module 604, in-vehicle heat dissipation and power consumption control module 605, in-vehicle anomaly protection and execution guarantee module 606, and in-vehicle data recording and log storage module 607.

[0084] The 601 in-vehicle Android device is an intelligent in-vehicle terminal device developed based on the in-vehicle Android device operating system and specifically designed for use in the automotive cabin environment. It is typically integrated into the vehicle's central control unit and has a processor, RAM, storage unit, display screen, audio module, and various automotive-grade hardware interfaces. It can run functions such as in-vehicle navigation, multimedia playback, Bluetooth communication, vehicle settings, voice interaction, and aging tests. It can also interact with the vehicle bus, sensors, and external devices, making it the core hardware carrier for realizing intelligent automotive interaction and in-vehicle program operation.

[0085] The vehicle-mounted device hardware monitoring module 602 can collect hardware operating parameters such as device temperature, memory usage, processor load, and power supply voltage of the vehicle-mounted Android device in real time, continuously monitor whether the hardware is in the normal operating range, and provide real-time data support for the system to determine whether to terminate the task and adjust resource allocation, ensuring that the hardware status can be monitored and warned during the aging test.

[0086] The vehicle-mounted task resource scheduling and management module 603 is responsible for the unified management of resource allocation for aging test tasks and various pending tasks. It dynamically plans the task execution order based on task priority, resource requirements, and available system resources. When resources are insufficient or the device status is abnormal, it quickly executes task start-stop strategies to ensure that the resources of the vehicle-mounted Android device operating system are reasonably allocated and to prioritize the operation of core test tasks.

[0087] The vehicle-mounted task execution status monitoring module 604 is used to track the execution progress, execution frame rate, task response latency and other operating statuses of aging test tasks in real time, quantitatively characterize the execution smoothness and stability of aging test tasks, and promptly identify situations such as task lag, interruption and execution abnormality, providing status basis for the system to decide whether to terminate other tasks.

[0088] The vehicle-mounted heat dissipation and power consumption control module 605 can automatically adjust the processor frequency, the number of background tasks and hardware power consumption according to the temperature of the vehicle-mounted device. When the temperature exceeds the preset threshold, it actively reduces non-core loads and uses task termination strategies to alleviate device overheating, avoid hardware frequency reduction or functional abnormalities caused by high temperature, and maintain the continuous and stable operation of the vehicle-mounted Android device during aging tests.

[0089] The vehicle-mounted anomaly protection and execution assurance module 606 is used to quickly respond to and execute preset protection strategies in abnormal scenarios such as excessive equipment temperature and low test frame rate, automatically terminate non-core target tasks to be executed, release system resources, ensure that aging test tasks are not disturbed, and ensure that the test process is not interrupted and the test results are true and valid.

[0090] The vehicle data recording and log storage module 607 is responsible for recording the device status data, task scheduling records, resource allocation records, and anomaly handling logs throughout the aging test process. It saves information such as device temperature, frame rate changes, and task start and stop times for subsequent analysis of aging test results and review of system scheduling strategies, providing data reference for optimizing the performance of the vehicle Android device operating system.

[0091] In summary, implementing the embodiments of the present invention has the following beneficial effects: As can be seen, the resource scheduling method based on aging test of in-vehicle Android devices described in this embodiment of the invention is applied to the operating system of an in-vehicle Android device. When performing aging test on a target in-vehicle Android device, the initial idle resource amount corresponding to the in-vehicle Android device operating system is first obtained. Then, n tasks to be executed corresponding to the in-vehicle Android device and n resource requirements corresponding to the n tasks to be executed are determined. Next, the priority of each of the n tasks to be executed is determined to obtain n priorities. Finally, based on the initial idle resource amount, the n resource requirements, and the n priorities, k target tasks to be executed from the n tasks to be executed are determined, so that the in-vehicle Android device operating system executes the k target tasks to be executed. Under the premise of ensuring the normal execution of the aging test of the in-vehicle Android device, the idle resource utilization efficiency of the in-vehicle Android device operating system is improved.

[0092] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a resource scheduling device based on aging test of vehicle-mounted Android device provided in an embodiment of this application. The resource scheduling device 700 based on aging test of vehicle-mounted Android device includes: an acquisition unit 701 and a processing unit 702. The acquisition unit 701 is used to acquire the initial free resource amount corresponding to the operating system of the vehicle Android device when performing an aging test on the target vehicle Android device. The processing unit 702 is used to determine n tasks to be executed corresponding to the vehicle-mounted Android device, and n resource requirements corresponding to the n tasks to be executed; each task to be executed corresponds to a resource requirement. Determine the priority of each of the n tasks to be executed, thus obtaining n priorities; Based on the initial amount of available resources, the n resource requirements, and the n priorities, k target tasks are determined from the n tasks to be executed, so that the in-vehicle Android device operating system executes the k target tasks to be executed; k is an integer less than or equal to n.

[0093] In some possible implementations, in determining the priority of each of the n tasks to be executed, and obtaining n priorities, the processing unit 702 is specifically used for: Obtain the task attribute data corresponding to the in-vehicle Android device; Based on the task attribute data, determine the urgency value of each of the n tasks to be executed, and obtain n urgency values; The n priorities are determined based on the n urgency values; the higher the urgency value of the task to be executed, the higher the priority of the task to be executed.

[0094] In some possible implementations, when the first task to be executed is a hardware self-test; the first task to be executed is one of the n tasks to be executed; based on the task attribute data, the urgency value corresponding to each of the n tasks to be executed is determined to obtain n urgency value surfaces, and the processing unit 702 is specifically used for: Based on the task attribute data, determine the degree of overlap and resource coupling between the hardware modules corresponding to the execution of the first task to be executed and the aging test; Determine a first urgency value corresponding to the overlap degree of the hardware module and a second urgency value corresponding to the resource coupling degree; The urgency value corresponding to the first task to be executed is determined based on the first urgency value and the second urgency value.

[0095] In some possible implementations, in determining the urgency value corresponding to the first task to be executed based on the first urgency value and the second urgency value, the processing unit 702 is specifically configured to: Determine a first weight corresponding to the first urgency value and a second weight corresponding to the second urgency value; the sum of the first weight and the second weight is 1; A reference urgency value is determined based on the first urgency value, the second urgency value, the first weight, and the second weight; Obtain the execution duration corresponding to the first task to be executed; Determine the adjustment parameters corresponding to the execution duration; The reference urgency value is adjusted based on the adjustment parameters to obtain the urgency value corresponding to the first task to be executed.

[0096] In some possible implementations, in determining k target tasks from the n tasks to be executed based on the initial resource availability, the n resource requirements, and the n priorities, the processing unit 702 is specifically used for: According to the n priorities in descending order, determine whether the resource requirement of the task to be executed corresponding to the current priority is less than or equal to the current available resource amount; when the current priority is the highest priority, the current available resource amount is the initial resource idle amount; If not, skip the task to be executed corresponding to the current priority; the current available resource amount remains unchanged; If so, the task to be executed corresponding to the current priority is determined as the target task to be executed, and the resource requirement of the task to be executed corresponding to the current priority is subtracted from the current available resource amount to obtain the current available resource amount corresponding to the next priority, until the n tasks to be executed are traversed to obtain the k target tasks to be executed.

[0097] In some possible implementations, the processing unit 702 is further specifically used for: When performing the aging test on the target vehicle Android device and the k target tasks to be executed, the device temperature and aging test task execution frame rate corresponding to the target vehicle Android device are obtained; the aging test task execution frame rate is used to characterize the smoothness of the aging test task execution. If the device temperature is higher than the preset temperature and / or the aging test task execution frame rate is lower than the preset execution frame rate, the execution of the k target tasks to be executed will be terminated to ensure the normal execution of the aging test.

[0098] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device is used in an in-vehicle Android device operating system, such as... Figure 8 As shown, the electronic device 800 includes a transceiver 801, a processor 802, and a memory 803. These are connected via a bus 804. The memory 803 stores computer programs and data, and the transceiver 801 can transmit data stored in the memory 803 to the processor 802. The program includes instructions for performing the following steps: When performing an aging test on the target in-vehicle Android device, obtain the initial amount of free resources corresponding to the operating system of the in-vehicle Android device; Determine n tasks to be executed corresponding to the in-vehicle Android device, and n resource requirements corresponding to the n tasks to be executed; each task to be executed corresponds to one resource requirement; Determine the priority of each of the n tasks to be executed, thus obtaining n priorities; Based on the initial amount of available resources, the n resource requirements, and the n priorities, k target tasks are determined from the n tasks to be executed, so that the in-vehicle Android device operating system executes the k target tasks to be executed; k is an integer less than or equal to n.

[0099] In some possible implementations, in determining the priority of each of the n tasks to be executed, and thus obtaining n priorities, the above procedure includes instructions for performing the following steps: Obtain the task attribute data corresponding to the in-vehicle Android device; Based on the task attribute data, determine the urgency value of each of the n tasks to be executed, and obtain n urgency values; The n priorities are determined based on the n urgency values; the higher the urgency value of the task to be executed, the higher the priority of the task to be executed.

[0100] In some possible implementations, when the first task to be executed is a hardware self-test; the first task to be executed is one of the n tasks to be executed; based on the task attribute data, the urgency value corresponding to each of the n tasks to be executed is determined to obtain n urgency value surfaces, and the above program includes instructions for performing the following steps: Based on the task attribute data, determine the degree of overlap and resource coupling between the hardware modules corresponding to the execution of the first task to be executed and the aging test; Determine a first urgency value corresponding to the overlap degree of the hardware module and a second urgency value corresponding to the resource coupling degree; The urgency value corresponding to the first task to be executed is determined based on the first urgency value and the second urgency value.

[0101] In some possible implementations, in determining the urgency value corresponding to the first task to be executed based on the first urgency value and the second urgency value, the above procedure includes instructions for performing the following steps: Determine a first weight corresponding to the first urgency value and a second weight corresponding to the second urgency value; the sum of the first weight and the second weight is 1; A reference urgency value is determined based on the first urgency value, the second urgency value, the first weight, and the second weight; Obtain the execution duration corresponding to the first task to be executed; Determine the adjustment parameters corresponding to the execution duration; The reference urgency value is adjusted based on the adjustment parameters to obtain the urgency value corresponding to the first task to be executed.

[0102] In some possible implementations, the above procedure includes instructions for performing the following steps in determining k target tasks from the n tasks to be executed based on the initial amount of available resources, the n resource requirements, and the n priorities: According to the n priorities in descending order, determine whether the resource requirement of the task to be executed corresponding to the current priority is less than or equal to the current available resource amount; when the current priority is the highest priority, the current available resource amount is the initial resource idle amount; If not, skip the task to be executed corresponding to the current priority; the current available resource amount remains unchanged; If so, the task to be executed corresponding to the current priority is determined as the target task to be executed, and the resource requirement of the task to be executed corresponding to the current priority is subtracted from the current available resource amount to obtain the current available resource amount corresponding to the next priority, until the n tasks to be executed are traversed to obtain the k target tasks to be executed.

[0103] In some possible implementations, the above procedure includes instructions for performing the following steps: When performing the aging test on the target vehicle Android device and the k target tasks to be executed, the device temperature and aging test task execution frame rate corresponding to the target vehicle Android device are obtained; the aging test task execution frame rate is used to characterize the smoothness of the aging test task execution. If the device temperature is higher than the preset temperature and / or the aging test task execution frame rate is lower than the preset execution frame rate, the execution of the k target tasks to be executed will be terminated to ensure the normal execution of the aging test.

[0104] It should be understood that the electronic devices mentioned in this application may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablets, PDAs, laptops, mobile internet devices (MIDs) or wearable devices, servers, edge computing nodes, etc. The above-mentioned electronic devices are merely examples and not exhaustive, and include, but are not limited to, the electronic devices described above.

[0105] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the methods described in the above method embodiments.

[0106] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0107] It should be noted that, for the sake of simplicity, the aforementioned methods are described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are optional, and the actions and modules involved are not necessarily essential to this application.

[0108] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0110] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0111] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0112] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0113] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0114] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A resource scheduling method based on aging test of in-vehicle Android devices, characterized in that, The method, applied to an in-vehicle Android device operating system, includes: When performing an aging test on the target in-vehicle Android device, obtain the initial amount of free resources corresponding to the operating system of the in-vehicle Android device; Determine n tasks to be executed corresponding to the in-vehicle Android device, and n resource requirements corresponding to the n tasks to be executed; each task to be executed corresponds to one resource requirement; Determine the priority of each of the n tasks to be executed, thus obtaining n priorities; Based on the initial amount of available resources, the n resource requirements, and the n priorities, k target tasks are determined from the n tasks to be executed, so that the in-vehicle Android device operating system executes the k target tasks to be executed; k is an integer less than or equal to n.

2. The method as described in claim 1, characterized in that, The step of determining the priority of each of the n tasks to be executed yields n priorities, including: Obtain the task attribute data corresponding to the in-vehicle Android device; Based on the task attribute data, determine the urgency value of each of the n tasks to be executed, and obtain n urgency values; The n priorities are determined based on the n urgency values; the higher the urgency value of the task to be executed, the higher the priority of the task to be executed.

3. The method as described in claim 2, characterized in that, When the first task to be executed is a hardware self-test; the first task to be executed is one of the n tasks to be executed; the step of determining the urgency value corresponding to each of the n tasks to be executed based on the task attribute data, resulting in n urgency values, includes: Based on the task attribute data, determine the degree of overlap and resource coupling between the hardware modules corresponding to the execution of the first task to be executed and the aging test; Determine a first urgency value corresponding to the overlap degree of the hardware module and a second urgency value corresponding to the resource coupling degree; The urgency value corresponding to the first task to be executed is determined based on the first urgency value and the second urgency value.

4. The method as described in claim 3, characterized in that, Determining the urgency value corresponding to the first task to be executed based on the first urgency value and the second urgency value includes: Determine a first weight corresponding to the first urgency value and a second weight corresponding to the second urgency value; the sum of the first weight and the second weight is 1; A reference urgency value is determined based on the first urgency value, the second urgency value, the first weight, and the second weight; Obtain the execution duration corresponding to the first task to be executed; Determine the adjustment parameters corresponding to the execution duration; The reference urgency value is adjusted based on the adjustment parameters to obtain the urgency value corresponding to the first task to be executed.

5. The method as described in claim 4, characterized in that, The process of determining k target tasks from the n tasks to be executed based on the initial available resources, the n resource requirements, and the n priorities includes: According to the n priorities in descending order, determine whether the resource requirement of the task to be executed corresponding to the current priority is less than or equal to the current available resource amount; when the current priority is the highest priority, the current available resource amount is the initial resource idle amount; If not, skip the task to be executed corresponding to the current priority; the current available resource amount remains unchanged; If so, the task to be executed corresponding to the current priority is determined as the target task to be executed, and the resource requirement of the task to be executed corresponding to the current priority is subtracted from the current available resource amount to obtain the current available resource amount corresponding to the next priority, until the n tasks to be executed are traversed to obtain the k target tasks to be executed.

6. The method as described in claim 5, characterized in that, The method further includes: When performing the aging test on the target vehicle Android device and the k target tasks to be executed, the device temperature and aging test task execution frame rate corresponding to the target vehicle Android device are obtained; the aging test task execution frame rate is used to characterize the smoothness of the aging test task execution. If the device temperature is higher than the preset temperature and / or the aging test task execution frame rate is lower than the preset execution frame rate, the execution of the k target tasks to be executed will be terminated to ensure the normal execution of the aging test.

7. A resource scheduling device based on aging test of in-vehicle Android devices, characterized in that, The device, which is used in an in-vehicle Android device operating system, includes: an acquisition unit and a processing unit; The acquisition unit is used to acquire the initial free resource amount corresponding to the operating system of the vehicle Android device when performing an aging test on the target vehicle Android device. The processing unit is used to determine n tasks to be executed corresponding to the in-vehicle Android device, and n resource requirements corresponding to the n tasks to be executed; each task to be executed corresponds to one resource requirement. Determine the priority of each of the n tasks to be executed, thus obtaining n priorities; Based on the initial available resources, the n resource requirements, and the n priorities, k target tasks are determined from the n tasks to be executed, so that the in-vehicle Android device operating system can perform the execution operation on the k target tasks to be executed; k is an integer less than or equal to n.

8. An electronic device, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the one or more programs include instructions for performing the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-6.

Images