Hardware testing system and hardware testing method based on Android Native layer and storage medium

Abstract

The invention relates to a hardware testing system and method based on an Android Native layer and a storage medium, the Native layer comprises a man-machine interface kernel and a use case agent module, the man-machine interface kernel is in communication connection with the use case agent module, and the use case agent module is in communication connection with the man-machine interface kernel. And the execution module is configured to respond to a hardware test instruction sent by the man-machine interface kernel and execute a target hardware test case corresponding to the hardware test instruction. By adopting the technical scheme, the hardware testing system is built on the Native layer for hardware testing, so that the hardware testing system is completely decoupled from the framework layer and the runtime environment of the Android system, the hardware testing does not depend on the framework layer and the runtime environment any more, the execution of the hardware testing is not influenced when the framework layer and the runtime environment go wrong, and the hardware testing efficiency is improved. And the system stability is improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of hardware testing, and in particular to a hardware testing system, a hardware testing method and a storage medium based on an Android Native layer. Background Art

[0002] The vehicle computer system hardware is the basis for supporting the complete operation of the entire vehicle computer system. It is very necessary to test the vehicle computer system hardware to detect the hardware quality.

[0003] At present, the testing of vehicle system hardware is achieved by installing a test application (Application, APP) on the vehicle system (mostly Android system). The test APP is installed in the application layer (APP layer) of the Android system, which relies on the framework layer (Framework layer) and runtime library layer (Android Runtime layer) of the Android system. When problems occur in the Framework layer or the Android Runtime layer, it will affect the operation of the test APP and the stability is poor. In addition, when testing, the entire architecture of the Android system needs to be started, and the startup speed is relatively slow, which affects the test efficiency. Summary of the invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, at least one embodiment of the present disclosure provides a hardware testing system, a hardware testing method and a storage medium based on the Android Native layer.

[0005] In a first aspect, the present disclosure provides a hardware testing system based on an Android Native layer, wherein the Native layer includes: a human-machine interface kernel and a use case proxy module, wherein the human-machine interface kernel and the use case proxy module are communicatively connected, wherein:

[0006] The use case proxy module is configured to execute a target hardware test case corresponding to the hardware test instruction in response to the hardware test instruction sent by the human-machine interface core.

[0007] In a second aspect, the present disclosure provides a hardware testing method based on the hardware testing system based on the Android Native layer in the first aspect, comprising:

[0008] Get hardware test instructions;

[0009] The hardware test instruction is sent to a use case proxy module, so that the use case proxy module responds to the hardware test instruction and executes a target hardware test case corresponding to the hardware test instruction.

[0010] In a third aspect, the present disclosure provides a computer-readable storage medium, which stores a program or instruction, and the program or instruction enables a computer to execute any hardware testing method of the hardware testing system based on the Android Native layer described in the first aspect provided by the embodiments of the present disclosure.

[0011] In a fourth aspect, the present disclosure provides a vehicle, comprising the hardware testing system based on the Android Native layer as described in the first aspect or the computer-readable storage medium as described in the third aspect.

[0012] In a fifth aspect, the present disclosure provides a computer program product, which is used to execute any hardware testing method based on the hardware testing system based on the Android Native layer described in the first aspect provided by the embodiments of the present disclosure.

[0013] Compared with the prior art, the technical solution provided by the embodiments of the present disclosure has at least the following advantages:

[0014] In the disclosed embodiment, a human-machine interface kernel and a use case proxy module are set in the Native layer of the Android system, and the human-machine interface kernel and the use case proxy module are connected in communication, and the use case proxy module is configured to respond to the hardware test instruction sent by the human-machine interface kernel and execute the target hardware test case corresponding to the hardware test instruction. The above technical solution is adopted to build a hardware test system based on the Native layer of Android, so that there is no need to start the entire framework of the Android system during hardware testing, which improves the startup speed, and the hardware test system is built based on the Native layer. After the development of the Native layer is completed, hardware testing can be performed without waiting for the upper architecture of the Native layer to be developed, which shortens the development and testing time and helps to improve R&D efficiency. In addition, the hardware test system is built in the Native layer for hardware testing, so that the hardware test system is completely decoupled from the framework layer and runtime environment of the Android system, and the hardware test no longer depends on the framework layer and runtime environment. Problems in the framework layer and runtime environment will not affect the execution of the hardware test, which improves the stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0017] Figure 1 A schematic diagram of the structure of a hardware testing system based on the Android Native layer provided in one embodiment of the present disclosure;

[0018] Figure 2 A schematic diagram of the structure of a hardware testing system based on the Android Native layer provided by another embodiment of the present disclosure;

[0019] Figure 3 A schematic diagram of the architecture of a hardware testing system based on the Android Native layer provided in a specific embodiment of the present disclosure;

[0020] Figure 4 This is a schematic diagram of the connection between modules in a specific embodiment of the present disclosure;

[0021] Figure 5 A flowchart of a hardware testing method provided by an embodiment of the present disclosure;

[0022] Figure 6 A schematic diagram of the structure of a hardware testing device provided in one embodiment of the present disclosure. DETAILED DESCRIPTION

[0023] In order to more clearly understand the above-mentioned purposes, features and advantages of the present disclosure, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It is understandable that the described embodiments are part of the embodiments of the present disclosure, rather than all of the embodiments, and the specific embodiments described herein are only used to explain the present disclosure, rather than to limit the present disclosure. In the absence of conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other. Based on the described embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in the field belong to the scope of protection of the present disclosure.

[0024] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0025] The existing vehicle system hardware testing by installing a test APP on the vehicle system has the following main problems:

[0026] (1) Since the test APP is based on the APP layer of the Android system, the entire Android system needs to be started before the test can begin. The startup speed is slow, which affects the test efficiency. In addition, the test process depends on the Framework layer and the Android Runtime layer. When problems occur in the Framework layer or the Android Runtime layer, the operation of the test APP will be affected, resulting in poor stability.

[0027] (2) When using the test app to perform high-temperature testing on the vehicle system hardware, since the operating temperature of the Android system is limited, when the temperature is high, the Android system will become abnormal and the test app will not work properly, thus interrupting the high-temperature test based on the test app;

[0028] (3) The Android system manages the test APP through the PackageManager management class. Since the PackageManager management class is shared by all APPs, other test users can also modify the PackageManager. These modifications may cause problems in the test APP. At this time, it is impossible to determine whether the problem is caused by the Android system itself or by other users' modifications, which makes the problem solving slow;

[0029] (4) The test APP runs in the user mode (normal mode) of the Android system to perform hardware testing. It requires the entire Android system to be started and has higher permissions. After the test, if the test user does not exit the test APP according to the normal operating steps, some modules in the normal mode will be in an abnormal state, causing problems in the Android system, affecting the normal operation of other APPs in the Android system, affecting the user experience, and solving the problem will also waste the time and energy of developers.

[0030] In response to the above problems, the present disclosure provides a hardware testing system based on the Android Native layer. The hardware testing system is built based on the Android Native layer (i.e., the system runtime layer, which mainly provides some local services and some link libraries, implemented in C and C++ languages, and used to provide native C / C++ libraries that can be used by different components of the Android system, such as multimedia libraries, layer management, system C language libraries, etc.), so that the entire framework of the Android system does not need to be started during hardware testing, which improves the boot speed. In addition, the hardware testing system is built based on the Native layer, and hardware testing can be performed after the Native layer is developed, without waiting for the upper architecture of the Native layer to be developed, thereby shortening the development and testing time, and also shortening the hardware design verification time, which helps to improve R&D efficiency. In addition, the hardware testing system is built at the Native layer for hardware testing, so that the hardware testing system is completely decoupled from the framework layer and runtime environment of the Android system, and the hardware test no longer depends on the framework layer and runtime environment. Problems in the framework layer and runtime environment will not affect the execution of the hardware test, which improves the system stability. Since the hardware testing system is completely decoupled from the framework layer and runtime of the Android system, when the hardware testing system is used to perform high-temperature testing on the hardware, the temperature monitoring architecture of the framework layer will not be triggered, so that the Android system will not be abnormal due to too high temperature, thereby avoiding the phenomenon of high-temperature testing being interrupted. The hardware testing system provided by the present disclosure is implemented based on the Native layer, rather than running on the APP layer, so that service management is not performed through the PackageManager management class, avoiding the phenomenon of exceptions caused by other test users modifying the PackageManager. When an exception occurs during the test, only the Native layer needs to be checked, which is convenient for discovering and solving problems, and helps to improve the speed of problem solving. The hardware testing system disclosed in the present disclosure is implemented based on the Native layer, so the entire Android system will not be started during testing, and it is completely isolated from the normal mode of the Android system, so it will not affect the user's use of other APPs and will not affect the user's experience.

[0031] Figure 1 This is a schematic diagram of the structure of a hardware testing system based on the Android Native layer provided by an embodiment of the present disclosure. Figure 1As shown, in the hardware testing system based on the Android Native layer provided by the embodiment of the present disclosure, the Native layer includes a human-machine interface kernel 110 and a use case proxy module 120, and the human-machine interface kernel 110 and the use case proxy module 120 are communicatively connected, wherein the use case proxy module 120 is configured with a test architecture for hardware testing in the human-machine interface kernel 110, and hardware test cases are loaded in the use case proxy module 120. When hardware testing is required, the human-machine interface kernel 110 sends a hardware testing instruction to the use case proxy module 120 based on the built-in test architecture. After receiving the hardware testing instruction, the use case proxy module 120 responds to the hardware testing instruction and executes the target hardware test case corresponding to the hardware testing instruction to implement hardware testing.

[0032] The use case proxy module 120 is configured to execute a target hardware test case corresponding to the hardware test instruction in response to the hardware test instruction sent by the human-machine interface core 110 .

[0033] Exemplarily, the human-machine interface core 110 and the use case proxy module 120 may be communicated with each other via a socket.

[0034] In the disclosed embodiment, the human-machine interface kernel 110 and the use case proxy module 120 interact to implement hardware testing, and the entire test framework structure is simpler. In addition, the test architecture is set in the human-machine interface kernel 110, and the hardware test cases are loaded by the use case proxy module 120, thereby achieving the isolation of the hardware test cases from the test architecture. When the test fails, it is easier to diagnose whether it is a hardware problem or a software problem, which reduces the difficulty of maintenance. The hardware test system disclosed in the present invention is executed at the Native layer, and there is no need to start the entire Android system. Therefore, hardware testing can be performed after the Native layer is started, and the execution rate is faster.

[0035] The hardware test system based on the Android Native layer of the disclosed embodiment sets a human-machine interface kernel and a use case proxy module in the Native layer of the Android system, and the human-machine interface kernel and the use case proxy module are connected in communication, and the use case proxy module is configured to respond to the hardware test instruction sent by the human-machine interface kernel and execute the target hardware test case corresponding to the hardware test instruction. The above technical scheme is adopted to build a hardware test system based on the Native layer of Android, so that there is no need to start the entire framework of the Android system during hardware testing, which improves the startup speed, and the hardware test system is built based on the Native layer. After the Native layer is developed, the hardware test can be carried out without waiting for the upper architecture of the Native layer to be developed, which shortens the development and testing time and helps to improve the research and development efficiency. In addition, the hardware test system is built in the Native layer for hardware testing, so that the hardware test system is completely decoupled from the framework layer and runtime environment of the Android system, and the hardware test no longer depends on the framework layer and runtime environment. Problems in the framework layer and runtime environment will not affect the execution of the hardware test, which improves the stability of the system.

[0036] In an optional embodiment of the present disclosure, Figure 2 As shown, in Figure 1 Based on the embodiment shown, the Native layer further includes a use case compilation module 130. The use case compilation module 130 is configured to compile the test cases corresponding to the test mode based on the test mode set by the user, and generate hardware test cases in a preset format.

[0037] In the disclosed embodiment, different test modes can be set in advance for different test indicators, for example, a test mode for testing a database unit (referred to as a DB mode), a test mode for testing electromagnetic compatibility (referred to as an EMC mode), a normal operation mode (also referred to as a user mode, a normal mode), and the like. Before the hardware test system is started, the user can first set the test mode for this test. Afterwards, during the process of starting the hardware test system, the use case compilation module 130 compiles the corresponding test case based on the test mode set by the user, and generates a hardware test case in a preset format (e.g., a .so format). In other words, the use case compilation module 130 implements the execution logic of the test case, and can compile each test case into a file in a preset format.

[0038] In the embodiment of the present disclosure, a plurality of different test modes are set for the hardware test system. At startup, the use case compilation module compiles corresponding test cases based on the test mode set by the user. Thus, the hardware test system of the present disclosure has its own unique startup mode. Furthermore, since the use case compilation module is set at the Native layer of the Android system, it only needs to be started to the Native layer at startup, without starting the upper framework of the Native layer in the Android system. Therefore, the startup speed is faster, and there is no need to wait for the upper framework of the Native layer to be developed, which helps to improve research and development efficiency.

[0039] Furthermore, in an optional implementation of the present disclosure, the use case proxy module 120 is also configured to load a hardware test case in a single process; wherein the number of the use case proxy modules 120 is consistent with the number of hardware test cases generated by the use case compilation module.

[0040] In the disclosed embodiment, when the hardware test system is started, the use case compilation module 130 compiles the corresponding test cases based on the test mode set by the user to generate hardware test cases in a preset format. Then, the use case proxy module 120 loads each generated hardware test case. When loading the hardware test case, a corresponding process is created for each generated hardware test case, and a hardware test case is loaded in a single process. That is to say, there is a use case proxy module 120 in a process for loading hardware test cases. If several hardware test cases are generated, there are several processes and several use case proxy modules 120 corresponding to them.

[0041] In the embodiment of the present disclosure, by configuring the use case proxy module to load a hardware test case in a single process, the execution of each hardware test case is independent. When multiple hardware test cases are executed at the same time, when a problem occurs in the execution of a hardware test case, the human-machine interface kernel 110 only needs to stop processing the event reported by the use case proxy module 120 to which the hardware test case with the problem belongs, which will not affect the execution of other hardware test cases, thereby ensuring the normal execution of other hardware test cases.

[0042] In an optional embodiment of the present disclosure, Figure 2 As shown, the Native layer also includes:

[0043] The communication module 140 is configured to communicate with the human-machine interface core 110 through a socket, and is used to communicate with a host computer.

[0044] In the disclosed embodiment, the communication module 140 communicates with the human-machine interface core 110 via a socket for data exchange, and the communication module 140 is also used to communicate with a host computer.

[0045] Furthermore, in an optional embodiment of the present disclosure, the use case agent module 120 is also configured to send the test results to the human-machine interface kernel 110; the human-machine interface kernel 110 is also configured to send the test results to the communication module 140 via a socket; the communication module 140 is also configured to send the test results to the host computer.

[0046] For example, the communication module 140 can receive the test instruction issued by the host computer, and send the test instruction to the human-machine interface kernel 110 through the socket. After the human-machine interface kernel 110 receives the test instruction, it can determine the hardware test case to be executed according to the test indicators, test parameters and other information carried in the test instruction, and send the hardware test instruction to the use case proxy module 120 that loads the hardware test case through the socket. After receiving the hardware test instruction, the use case proxy module 120 executes the loaded hardware test case and starts the test. After the test is completed, the use case proxy module 120 sends the test result to the human-machine interface kernel 110 through the socket, and the human-machine interface kernel 110 sends it to the communication module 140 through the socket, and then the communication module 140 sends the test result to the host computer.

[0047] In an optional embodiment of the present disclosure, Figure 2 As shown, the Native layer also includes:

[0048] The diagnosis module 150 is used for self-diagnosis of hardware test cases in the hardware test system.

[0049] In the disclosed embodiment, by setting a diagnostic module at the Native layer to diagnose hardware test cases, self-diagnosis of hardware test cases can be achieved, so as to timely discover problems existing in hardware test cases, improve the convenience of program diagnosis, and reduce the difficulty of maintenance.

[0050] In an optional embodiment of the present disclosure, Figure 2 As shown, the Native layer also includes:

[0051] The power management module 160 is used to control the sleep, restart or wake-up of the hardware test system.

[0052] In the embodiment of the present disclosure, the Native layer is provided with a power management module 160, which can be used to control the sleep, restart, wake-up, etc. of the hardware test system.

[0053] Figure 3 The schematic diagram of the architecture of the hardware testing system based on the Android Native layer provided in a specific embodiment of the present disclosure is as follows: Figure 3As shown in the figure, the Android system's Native layer adopts a layered design. Each layer is divided into different modules according to their functions, and the bottom modules provide services for the upper modules. Figure 3 As shown, the Native layer of the Android system is mainly divided into the following sub-layers: presentation layer, core layer, data layer, connection layer and dependency layer. Among them, the presentation layer provides an interface for interacting with the user and provides relevant interaction logic. This layer is mainly responsible for UI display and user interaction. The specific business logic call is implemented by the core layer; the core layer is the core of the hardware test system provided by the present disclosure. The scheduling of hardware test cases, the creation of hardware test case processes, the execution of hardware test cases, and the self-diagnosis of hardware test cases are all implemented in this layer; the data layer is used to save test results, record error codes, etc.; the connection layer is mainly used for communication and data interaction; the dependency layer is used to provide some runtime dependency environments.

[0054] like Figure 3 As shown, the presentation layer may include a main page module and a test page module. The core layer may specifically include the following modules: a man-machine interface kernel (MMI core), a use case agent module (Agent), a use case compilation module (TestCase) and a diagnostic module (Diag), wherein the man-machine interface kernel is used to manage and control the execution of hardware test cases and the processing of test results, for example, judging whether the test indicator is tested or not according to the returned test results and the test parameters expected by the test indicators, and feeding back the test result to the host computer through the communication module; the use case agent module is used to load a hardware test case in a single process, and communicate with the man-machine interface kernel through a socket, and execute the hardware test case based on the hardware test instruction sent by the man-machine interface kernel; the use case compilation module implements the execution logic of the test case, and is used to compile each test case to generate a corresponding so file; the diagnostic module is used for self-diagnosis of hardware test cases in the hardware test system.

[0055] The data layer can include a database module (Database), a memory module (Memory) and a file storage module (File). Different modules can be used to store different data. The data type stored in each module can be set according to actual needs. The connection layer can include a remote service module (RemoteService) and a communication module (CommandReceiver). The remote service module is mainly used for communication between the system on chip (System on Chip, SOC) and 5G and the micro control unit (Micro Control Unit, MCU), and for the Native layer on the SOC to communicate with the underlying QNX layer, calling some drivers (Driver) to obtain relevant hardware test data, such as the temperature data of the SOC, the identification and related information of the universal flash storage (Universal Flash Storage, UFS), etc.; the communication module is mainly used to communicate with the host computer, receive host computer instructions, and return test results to the host computer. It also communicates with the human-machine interface kernel through the socket, conveys the host computer's instructions to the human-machine interface kernel through the socket, and feeds back the test results returned by the human-machine interface kernel through the socket to the host computer.

[0056] The dependency layer includes a power management module (PowerManagerForDV), a data distribution service module (DDS), a remote procedure call module (RPC), a graphics library (SKIA), and a data storage module (Apache Arrow), wherein the power management module is used to control the sleep, restart, wake-up, etc. of the hardware test system; the data distribution service module is used to provide support for the communication between SOC and 5G; the remote procedure call module is used to provide support for the communication between SOC and MCU; the graphics library is used to realize the display of the user interface; the data storage module is used to provide support for the database. In some embodiments, the dependency layer may also include a vehicle hardware abstraction layer (VHAL) interface, which is an encapsulation interface made on the upper layer of the data distribution service module and the remote procedure call module, so that the data distribution service module and the remote procedure call module are exposed through a statistical interface.

[0057] from Figure 3It can be seen that the hardware testing system based on the Android Native layer provided by the present invention modifies the Native layer on the basis of the original kernel (kernel) and hardware abstraction layer (HAL) of the Android system, and builds a hardware testing system by setting modules such as the human-machine interface kernel, the use case proxy module, and the use case compilation module in the Native layer. When using the hardware testing system to perform hardware testing, there is no need to rely on the upper-layer architecture of the Native layer, so that the hardware testing process is decoupled from the Framework layer and its upper layers of the Android system, forming a small hardware testing system. The hardware is tested directly through the Native layer and will not be affected by changes in the functions of the Framework layer and its upper layers, thereby increasing system stability.

[0058] Figure 4 FIG. 1 is a schematic diagram of the connection between modules in a specific embodiment of the present disclosure. Figure 4 As shown, the human-machine interface kernel includes a human-machine interface control unit and a module calling unit, wherein the human-machine interface control unit is connected to the communication module through a socket, and is used to receive instructions sent by the upper computer and conveyed by the communication module, and to feed back test results to the upper computer through the communication module; the module calling unit is connected to the use case proxy module through a socket, and when the human-machine interface kernel receives a hardware test instruction, the module calling unit sends the hardware test instruction to the corresponding use case proxy module through the socket, so that the use case proxy module executes the loaded hardware test case. Figure 4 It can be seen that a use case proxy module loads a hardware test case in a single process, and n hardware test cases are loaded by creating n processes. Each use case proxy module communicates with the human-machine interface kernel through a socket. When a problem occurs in the execution of a hardware test case, it does not affect the execution of other hardware test cases. The power management module can be connected to the human-machine interface kernel to control the restart, sleep, wake-up, etc. of the human-machine interface kernel, thereby realizing the restart, sleep, wake-up, etc. of the hardware test system.

[0059] It should be noted that Figure 4 The setting of the diagnostic module in the human-machine interface kernel is only used as an example and cannot be used as a limitation of the present disclosure. The diagnostic module can also be set outside the human-machine interface kernel. As long as the self-diagnosis of the hardware test case can be guaranteed, the present disclosure does not limit the setting location of the diagnostic module.

[0060] Figure 5 The flowchart of the hardware testing method provided by an embodiment of the present disclosure is a schematic diagram. The hardware testing method is implemented based on the hardware testing system based on the Android Native layer described in the above embodiment. Figure 5 As shown, the hardware testing method may include the following steps:

[0061] Step 501, obtaining hardware test instructions.

[0062] Exemplarily, the hardware test instruction may be issued by a user (tester) through a host computer, and the hardware test instruction may include information such as test indicators and test parameters.

[0063] Step 502: Send the hardware test instruction to the use case proxy module, so that the use case proxy module responds to the hardware test instruction and executes the target hardware test case corresponding to the hardware test instruction.

[0064] In the disclosed embodiment, the human-machine interface kernel of the hardware test system can obtain hardware test instructions through the communication module connected to its socket. After the user issues the hardware test instruction through the host computer, the hardware test instruction first reaches the communication module set in the Native layer, and is sent to the human-machine interface kernel through the socket by the communication module. After the human-machine interface kernel receives the hardware test instruction, it can send the hardware test instruction to the use case proxy module through the socket. After receiving the hardware test instruction, the use case proxy module responds to the instruction and executes the target hardware test case corresponding to the hardware test instruction.

[0065] After the use case proxy module executes the target hardware test case, it can send the test results to the human-machine interface kernel through the socket. The human-machine interface kernel can process the test results, for example, determine whether the test passes based on the test results, and send the test results and / or judgment results to the communication module through the socket, which will be fed back to the host computer by the communication module.

[0066] In some optional embodiments, the use case proxy module can be configured to load a hardware test case in a single process. When there are multiple hardware test cases, multiple processes need to be created to load the hardware test cases. One hardware test case is loaded by one use case proxy module. In this case, after the human-machine interface kernel receives the hardware test instruction, it can first parse out the relevant test information carried in the hardware test instruction, determine the use case proxy module that needs to perform the test operation based on the test information, and then send a test instruction (such as a run instruction) to the use case proxy module. After receiving the test instruction, the use case proxy module can execute the loaded hardware test case and start the test.

[0067] The hardware testing method provided by the embodiment of the present disclosure is implemented by using a hardware testing system based on the Android Native layer. By obtaining hardware testing instructions, the hardware testing instructions are sent to the use case proxy module, so that the use case proxy module responds to the hardware testing instructions and executes the target hardware test case corresponding to the hardware testing instructions, thereby realizing hardware testing. Since the hardware testing system of the present disclosure is built based on the Android Native layer, it is not necessary to start the entire framework of the Android system during hardware testing, which improves the startup speed. Moreover, the hardware testing system is built based on the Native layer, and hardware testing can be performed after the Native layer is developed, without waiting for the upper architecture of the Native layer to be developed, which shortens the development and testing time and helps to improve R&D efficiency. In addition, the hardware testing system is built at the Native layer for hardware testing, so that the hardware testing system is completely decoupled from the framework layer and runtime environment of the Android system, and the hardware test no longer depends on the framework layer and runtime environment. Problems in the framework layer and runtime environment will not affect the execution of the hardware test, which improves the stability of the system.

[0068] In order to implement the above embodiments, the present disclosure also provides a hardware testing device.

[0069] Figure 6 This is a schematic diagram of the structure of a hardware testing device provided in an embodiment of the present disclosure. The device can be implemented using software and / or hardware and can be applied to a vehicle.

[0070] like Figure 6 As shown, the hardware testing device 60 provided in the embodiment of the present disclosure may include: an acquisition module 601 and a sending module 602, wherein:

[0071] An acquisition module 601 is used to acquire a hardware test instruction;

[0072] The sending module 602 is used to send the hardware test instruction to the use case agent module, so that the use case agent module responds to the hardware test instruction and executes the target hardware test case corresponding to the hardware test instruction.

[0073] The hardware testing device provided in the embodiments of the present disclosure and which can be configured on a vehicle can execute any hardware testing method provided in the embodiments of the present disclosure and which is applied to a vehicle and is based on the hardware testing system based on the Android Native layer described in the aforementioned embodiments, and has the corresponding functional modules and beneficial effects of the execution method. For the contents not fully described in the embodiments of the present disclosure, reference can be made to the description in any method embodiment of the present disclosure.

[0074] The embodiments of the present disclosure also provide a computer-readable storage medium, which is non-transitory and stores programs or instructions. The programs or instructions enable a computer to execute the steps of each embodiment of the hardware testing method based on the hardware testing system based on the Android Native layer as described in any of the aforementioned embodiments. To avoid repeated description, they are not repeated here.

[0075] The embodiments of the present disclosure also provide a vehicle, including the hardware testing system based on the Android Native layer as described in the aforementioned embodiments or the computer-readable storage medium as described in the aforementioned embodiments.

[0076] The embodiments of the present disclosure further provide a computer program product, which is used to execute the steps of each embodiment of the hardware testing method based on the hardware testing system based on the Android Native layer as described in any of the aforementioned embodiments.

[0077] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0078] The above description is only a specific embodiment of the present disclosure, so that those skilled in the art can understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A hardware testing system based on the Android Native layer, characterized in that: The Native layer includes: a human-machine interface kernel and a use case proxy module, wherein the human-machine interface kernel and the use case proxy module are communicatively connected, wherein: The use case proxy module is configured to execute a target hardware test case corresponding to the hardware test instruction in response to the hardware test instruction sent by the human-machine interface core.

2. The system according to claim 1, characterized in that The Native layer also includes: The use case compilation module is configured to compile the test cases corresponding to the test mode set by the user and generate hardware test cases in a preset format.

3. The system according to claim 2, characterized in that The use case proxy module is further configured as follows: loading a hardware test case in a single process; The number of the use case proxy modules is consistent with the number of hardware test cases generated by the use case compilation module.

4. The system according to claim 1, characterized in that The Native layer also includes: The communication module is configured to communicate with the human-machine interface core through a socket and is used to communicate with a host computer.

5. The system according to claim 4, characterized in that The use case proxy module is further configured to send a test result to the human-machine interface kernel; wherein the test result is a result obtained after executing the target hardware test case; The human-machine interface core is further configured to send the test result to the communication module through the socket; The communication module is further configured to send the test result to the host computer.

6. The system according to claim 1, characterized in that The Native layer also includes: The diagnostic module is used for self-diagnosis of hardware test cases in the hardware test system.

7. The system according to claim 1, characterized in that The Native layer also includes: The power management module is used to control the sleep, restart or wake-up of the hardware test system.

8. A hardware testing method based on the hardware testing system based on the Android Native layer according to any one of claims 1 to 7, characterized in that: The method comprises: Get hardware test instructions; The hardware test instruction is sent to a use case proxy module, so that the use case proxy module responds to the hardware test instruction and executes a target hardware test case corresponding to the hardware test instruction.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a program or an instruction, wherein the program or the instruction enables a computer to execute the hardware testing method according to claim 8.

10. A vehicle, characterized in that: It includes the hardware testing system based on the Android Native layer as described in any one of claims 1 to 7 or the computer-readable storage medium as described in claim 9.

Images