Semi-random automatic testing method and system for Android local library
By building a unified cross-language APK and state transition event library, and generating semi-random test cases, the problem of insufficient scalability and coverage of Android native library testing is solved, and efficient and targeted automated testing is achieved.
Patent Information
- Application Number
- CN202511356637.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-22
- Publication Date
- 2026-01-20
AI Technical Summary
Existing Android native library testing methods suffer from scalability issues, insufficient accuracy, low efficiency, reliance on source code or interface documentation limitations, insufficient random test coverage, and difficulty in triggering deep logic.
By reverse engineering to generate a list of native library functions, a unified cross-language APK is built, an App state-UI-cross-language function call relationship graph is established, a state transition event library is generated, test cases are generated using a semi-random strategy, and automated testing is performed by combining multiple testing strategies.
It significantly improves the targeting and coverage of tests, efficiently triggers deep local functions, reduces redundant tests, and improves the level and efficiency of test automation.
Smart Images
Figure CN121364997A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present document relates to the technical field of software testing, and particularly relates to a semi-random automated testing method and system for an Android native library. BACKGROUND
[0002] Since the call of the native library function in the Android App is not a direct native layer call, but a call of the native layer by the managed layer, the analysis of the native library function call belongs to cross-language analysis, which is more complex than traditional non-cross-language function call analysis.
[0003] In the Android App, the managed layer code (Java / Kotlin) can call the native library function (C / C++) through the Java Native Interface (JNI). At the same time, the native library function can also call the managed layer function through JNI. At present, in the aspect of cross-language call, most studies try to combine native code with Dex bytecode for unified static analysis. However, this analysis strategy has many limitations, therefore, the existing Android native code analysis technology either has scalability problems or cannot guarantee sufficient accuracy. The native library functions can also call each other directly, and if only the calls of the managed layer code are analyzed, many native layer calls will be ignored, resulting in incomplete analysis. Similarly, if only the calls of the managed layer to the native layer through JNI are considered, and the calls between the native layers are ignored, the analysis will also be incomplete.
[0004] The native library plays an important role in the Android App. However, in the existing testing methods, some methods are not highly targeted for Android native libraries; some methods depend on source code or interface documents for testing effect.
[0005] In the testing method for the Android App, the traditional testing method usually needs to generate valid input and explore each branch of the program. However, in this process, the testing tool often encounters the problem of path explosion, in addition, the constraint solving of the branch condition also faces high computational complexity; and such methods have weak targeting for native library functions; these challenges result in low testing efficiency. At present, the testing method for the Android native library mainly relies on fuzz testing, however, it also faces the problem of path explosion, on the other hand, although the source code of the Android App or the native library can improve the testing effect of the fuzz testing, the Android App, the native library code may be closed source or lack of interface documents, which limits the testing effect of the fuzz testing. Although the random testing method can solve the above problems, it also has certain limitations in the testing of the Android native library. The random testing method covers the program path by generating a large number of random events, but the triggering ability of deep logic is weak, resulting in insufficient coverage. SUMMARY
[0006] The one or more embodiments of the specification provide a semi-random automated testing method for Android native library, comprising: S1: taking an Android APK as input, generating a native library function list; S2: converting C / C++ code in the APK into Java bytecode and repackaging to obtain a cross-language unified APK; S3: based on the cross-language unified APK, constructing a composite call relationship graph containing App state, UI and cross-language function call; S4: according to the composite call relationship graph, guiding random testing to generate a state transition event library; S5: based on the state transition event library, generating a test case pool using permutation and combination strategy; S6: selecting test cases from the test case pool to perform semi-random automated testing on Android native library functions.
[0007] Further, in S1, the function signature is extracted by reverse engineering and analyzing the dynamic link library file, the function signature including function name, symbol and entry address, forming the native library function list.
[0008] Further, in S2, the C / C++ source code is converted into Java bytecode as a whole by a bytecode converter, and repackaged with the original Java bytecode to form a cross-language unified APK.
[0009] Further, S3 further comprises: parsing the layout XML file to extract control identification, hierarchical relationship, geometric constraint and event listener binding information, forming a structured UI description file; based on the cross-language unified APK, constructing a cross-language function call graph, the cross-language function call graph including state functions and normal functions; associating and mapping the native library function list, the cross-language function call graph and the UI description file to generate the composite call relationship graph.
[0010] Further, S4 comprises: establishing a state transition event table for each adjacent (component, state) binary tuple in the composite call relationship graph; inserting a probe log in the cross-language unified APK, running a random event generation framework test and collecting logs, the logs including event information and probe trigger information; extracting the minimum event sequence that facilitates state transition through log backtracking, writing into the state transition event table to form the state transition event library.
[0011] Further, the state transition event table contains: event type field, taking values including click, long press, swipe, keyboard input, sensor event; input parameter field, recording coordinates, text, gesture track or sensor value; pre-state field and post-state field, respectively recording (component, state) binary tuple before and after triggering.
[0012] Further, the preset test strategy in S6 includes: full-amount strategy, function-oriented strategy, function coverage strategy, state coverage strategy and fast triggering strategy.
[0013] One or more embodiments of the present specification provide a semi-random automated testing system for Android native library, comprising: a list generation module: configured to generate a native library function list with Android APK as input; a packaging module: configured to convert C / C++ code in the APK into Java bytecode and repack to obtain a cross-language unified APK; a relationship graph construction module: configured to construct a composite call relationship graph containing App state, UI and cross-language function call based on the cross-language unified APK; an event library generation module: configured to generate a state transition event library according to the composite call relationship graph; a test case generation module: configured to generate a test case pool based on the state transition event library using permutation and combination strategy; a test module: configured to select test cases from the test case pool to perform semi-random automated testing on Android native library functions.
[0014] One or more embodiments of the present specification provide an electronic device, comprising: a processor; and a memory arranged to store computer executable instructions which, when executed, cause the processor to implement the steps of the above-mentioned semi-random automated testing method for Android native library.
[0015] One or more embodiments of the present specification provide a storage medium for storing computer executable instructions which, when executed, implement the steps of the above-mentioned semi-random automated testing method for Android native library.
[0016] The Android native library semi-random automatic testing method can significantly improve the pertinence, coverage and efficiency of testing. The application state, user interface and cross-language (Java / C++) function call are unified in the same model, and the problems of high blindness of traditional random testing and difficulty in triggering deep native functions are fundamentally overcome; based on the relationship graph, a state transition event library is generated, and a semi-random strategy is used to combine to generate test cases, which ensures the randomness of testing and has a guiding nature, can efficiently trigger C / C++ library functions at the bottom of the application, and effectively detect potential defects caused by parameter transmission, state transition or cross-language calling; in addition, the method provides multiple testing strategies, which can be flexibly adapted to different testing targets and resource constraints, while ensuring that key functions and state transition paths are fully covered, significantly reducing redundant testing, and improving the automation level and overall efficiency of testing.
[0017] The above description is only a summary of the technical solutions of the present application, in order to more clearly understand the technical means of the present application, the contents of the specification can be implemented, and in order to make the above and other purposes, characteristics and advantages of the present application more obvious and easy to understand, the specific embodiments of the present application are described below. BRIEF DESCRIPTION OF DRAWINGS
[0018] In order to more clearly illustrate the technical solutions in the one or more embodiments of the present application or the prior art, the drawings needed in the embodiment or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can obtain other drawings according to these drawings without creating additional labor.
[0019] Figure 1 A flowchart of a semi-random automatic testing method for Android native library is provided for one or more embodiments of the present application; Figure 2 A composition schematic diagram of a semi-random automatic testing system for Android native library is provided for one or more embodiments of the present application; Figure 3 A state transition event table structure schematic diagram is provided for one or more embodiments of the present application; Figure 4 A structure schematic diagram of an electronic device is provided for one or more embodiments of the present application. DETAILED DESCRIPTION
[0020] In order to make the person skilled in the art better understand the technical solutions in one or more embodiments of the present specification, the technical solutions in one or more embodiments of the present specification will be clearly and completely described in the following with reference to the drawings in one or more embodiments of the present specification. Obviously, the described embodiments are only a part of the embodiments of the present specification, not all. Based on one or more embodiments of the present specification, all other embodiments obtained by those skilled in the art without creative labor should belong to the protection scope of the present document.
[0021] Method embodiment According to an embodiment of the present application, a semi-random automated testing method for Android native library is provided, Figure 1 A flowchart of a semi-random automated testing method for Android native library provided by one or more embodiments of the present specification is shown in Figure 1 As shown, the semi-random automated testing method for Android native library according to an embodiment of the present application specifically includes: S1: Taking Android APK as input, generating a list of native library functions.
[0022] Taking Android APK as input, the dynamic link library file is parsed by reverse engineering, and the function signature is extracted, including function name, symbol and entry address, to form the list of native library functions.
[0023] S2: Convert the C / C++ code in the APK to Java bytecode and repack to get a cross-language unified APK.
[0024] The C / C++ source code is converted into Java bytecode as a whole by the bytecode converter, and is repacked with the original Java bytecode to form a cross-language unified APK, generating a new APK file.
[0025] S3: Based on the cross-language unified APK, a composite call relationship graph containing App state, UI and cross-language function call is constructed.
[0026] Taking XML file as input, parse layout XML file, extract control identification, hierarchical relationship, geometric constraint and event listener binding information, form structured UI description file; Specifically including layout information, view information, constraint layout information and event information. Layout information is the basic attribute of layout, such as ID, name, etc.; View information includes control elements on the interface, such as buttons, text boxes, etc.; Constraint layout information, such as the position and size of the view; Event information, including interactive events on the view, such as click, long press, etc.
[0027] Taking the unified and repackaged APK file with cross-language code as input, the function call relationships of native library functions are analyzed to generate a function call graph. The call graph describes the call chain between functions, including state functions and general functions, and the binding relationship between functions and the UI. Its data structure consists of the function call graph and a key-value pair storage structure recording the relationship between functions and the UI. The key is the function, and the value is the UI information bound to that function. Taking the APK file, UI information, function call graph, and list of native library functions as input, the list of native library functions, the cross-language function call graph, and the UI description file are associated and mapped to generate the composite call graph. Specifically, firstly, non-native library function calls are excluded based on the list of native library functions; nextly, based on the function call information, the UI information bound to the functions is obtained through event listeners in the Java layer code and XML files, ultimately resulting in the App state-UI-cross-language function call graph.
[0028] S4: Based on the composite call relationship diagram, guide random testing to generate a state transition event library.
[0029] For each adjacent (component, state) tuple in the composite call relationship graph, establish a state transition event table; the state transition event table is as follows: Figure 3 As shown, this is used to store state transition events and input sequences, including their respective states. Using a state transition event library and an APK file as input, an event and input sequence capable of implementing a state transition are obtained based on a random testing method and recorded in the corresponding state transition event table. The specific method is as follows: Add log as a marker at the code level for functions involved in the call relationship graph; Based on the call relationship diagram, find two adjacent state functions, corresponding to two states (xxx) and (yyy); Execute Monkey tests, trigger random events, and log the triggered events, input information, etc. Analyze the output logs to find the sequence of events that caused the transition between the two states mentioned above, even if (xxx). The event sequence of (yyy); Record the state transition event sequence into the corresponding state transition event table.
[0030] Insert probe logs into a cross-language unified APK, run a random event generation framework test and collect logs, the logs including event information and probe trigger information; The minimum sequence of events that leads to a state transition is extracted by backtracking the logs and written into the state transition event table to form the state transition event library.
[0031] First, the acquired Monkey test log is positioned adjacent state functions, then, events between the two state functions are searched and found one by one in the log, and then it is judged whether the found event is a valid state transition event. If an event (or a series of events) can cause the state transition of adjacent two states, the event (or event sequence) is considered to be a valid state transition event.
[0032] The state transition event table has two types, the first is the normal state transition, that is, the transition between two (components, states), which can be represented as (Component_i, state_i) (Component_j, state_j), the second is the final trigger state transition, that is, the state transition of (component, state) to the native library function, which can be represented as (Component_i, state_i) native library function.
[0033] The state transition event table includes: The event type field takes values including click, long press, swipe, keyboard input, and sensor event; The input parameter field records coordinates, text, gesture trajectory, or sensor value; The pre-state field and the post-state field record the (component, state) binary tuple before and after triggering, respectively.
[0034] S5: Based on the state transition event library, a permutation and combination strategy is used to generate a test case pool.
[0035] The test case construction adopts a permutation and combination strategy. First, the state transition event table sequence is constructed based on the call relationship graph and the state transition event library, and then the stored state transition events and inputs in the state transition event table are arranged and combined to generate all test cases.
[0036] Suppose the state transition event table sequence to the native library function is: (Component_i, state_i) (Component_j, state_j) native library function, (Component_i, state_i) (Component_j, state_j) The state transition event table records m state transitions and event input sequences, (Component_j, state_j)
[0037] S6: Select test cases from the test case pool to perform semi-random automated testing on the Android native library function.
[0038] After obtaining the test cases, the test cases are automatically executed to test the local library functions by generating test scripts. According to different test targets, preset test strategies include complete test, single function test, function coverage priority test, state transition coverage priority test and trigger priority test. Specifically: The complete test aims to run through all test cases. The single function test aims to trigger a single function given by a user. The function coverage priority test aims to trigger all local library functions. The state transition coverage priority test aims to run through all states. The trigger priority test only triggers the local library functions without considering parameters (may not start from the initial state).
[0039] Although the above five test targets are different, they all include the step of executing test cases. The execution of test cases can be divided into two ways: "starting from the initial state" and "not starting from the initial state".
[0040] The "starting from the initial state" mode considers the complete transmission of parameters. To ensure the completeness of parameters (a component, state is transferred from another component, state, which may need the parameters transmitted by the previous component, state to implement subsequent function calls), the test is performed from front to back according to the call sequence. Taking the WeChat "message interface" as an example, to go from the "message interface" to the "specific message interface", the message window of a certain contact needs to be clicked, so that the chat record with the contact can be displayed. If the "specific message interface" is directly jumped to, it cannot be correctly displayed due to the unknown contact information (i.e. parameters).
[0041] Since not all functions are triggered depending on the parameters transmitted by the previous state, the parameters can also be ignored, i.e. the test cases "do not start from the initial state", and directly locate to the component, state closest to the local library function to execute the test cases.
[0042] In the complete test, the target is to run through all test cases, and the steps are as follows: Obtain all local library functions; Obtain all test cases for each local library function; Execute the test cases (starting from the initial state); The target of the single function test is to trigger the target function given by the user, and the steps are as follows: For the target function, find all test cases that can trigger the target function; Randomly select a certain number of test cases (according to the number of test cases given by the user); Execute the test cases (starting from the initial state); In function coverage priority test, the goal is to trigger all local library functions, the steps are as follows: Find all test cases for each local library function; Randomly select one or more (user-defined number) test cases for each local library function to execute (starting from the initial state); Example: There are two test cases for the triggering of a certain local library function F1: (1) A -> B -> C -> local library function F1 (2) X -> Y -> Z -> local library function F1 Randomly select one of the test cases to execute.
[0043] In state transition coverage priority test, the goal is to cover all state transitions, the steps are as follows: Extract the call sequence: according to the function call relationship diagram, extract all call sequences; Establish a state transition mapping set: for each call sequence, extract all state transitions corresponding to it, and establish a "state transition Mapping relationship of "state transition Build a state transition set: traverse the above mapping set, extract all state transitions, and form a complete state transition set; Build a call sequence set: for each state transition in the state transition set, randomly select one or more (number can be user-defined) call sequences containing the state transition from the mapping set and add to the call sequence set; Select and execute test cases: for each call sequence in the call sequence set, get all its test cases, and randomly select one or more (number can be user-defined) to execute (starting from the initial state).
[0044] Example: In the call relationship diagram of a certain App, there are three call sequences, where uppercase letters are state functions and lowercase letters are general functions: (1) A -> x -> B -> y -> z -> C -> local library function F1; (2) A -> o -> B -> p -> D local library function F2; (3) A -> q -> B -> r -> s -> C -> local library function F1; First, a "state transition, calling sequence" mapping is established for them according to the three calling sequences. The first calling sequence obtains all the mapping relationships: (A -> B, sequence (1)), (B -> C, sequence (1)); the second calling sequence obtains all the mapping relationships: (A -> B, sequence (2)), (B -> D, sequence (2)). The third calling sequence obtains all the mapping relationships: (A -> B, sequence (3)), (B -> C, sequence (3)). The above six mapping relationships are added to a mapping relationship set.
[0045] Subsequently, all state transitions are obtained by traversing the above mapping set, that is, (A -> B), (B -> C) and (B -> D), and a state transition set (there is only one element of the same set in the set) is established.
[0046] Next, according to the user's requirements (here it is assumed that the user's requirements are to select one), a calling sequence is randomly selected for each state transition from the mapping set. A -> B has three sequences: sequence (1), sequence (2) and sequence (3); B -> C has two calling sequences: sequence (1) and sequence (3); B -> D has only one calling sequence: sequence (2). A calling sequence is randomly selected for each state transition, A -> B randomly selects sequence (1), B -> C randomly selects sequence (2), and B -> D randomly selects sequence (2), so the calling sequence set constructed includes two sequences: sequence (1) and sequence (2).
[0047] Finally, all test cases corresponding to each calling sequence are obtained and one or more (the number can be customized by the user) are randomly selected and executed.
[0048] The goal of the trigger priority test is to trigger the local library function as much as possible without considering the integrity of the parameters, and the steps are as follows: All test cases of each local library function are obtained; The execution of the test case no longer starts from the initial state, but from the state that can directly call the local library function.
[0049] Example: The local library function F1 has two test cases: (1) A -> B -> C -> local library function F1; (2) X -> Y -> Z -> local library function F1; Among the previous four test goals: The first test case needs to start from the initial state and execute A, B, and C in turn to ensure that the parameters are complete when F1 is triggered; The second test case needs to start from the initial state and execute X, Y, and Z in turn to ensure that the parameters are complete when F1 is triggered; In the test of the test target, we directly execute C from the state corresponding to C; and directly execute Z from the state corresponding to Z.
[0050] The present application has the following advantages: The Android native library semi-random automatic testing method provided by the present application can significantly improve the pertinence, coverage and efficiency of testing. By constructing an App state-UI-cross-language function call relationship graph, the application state, user interface and cross-language (Java / C++) function call are first unified in the same model, which fundamentally overcomes the high blindness of traditional random testing and the difficulty in triggering deep native functions; based on the relationship graph, a state transition event library is generated, and a semi-random strategy is used to generate test cases, which not only ensures the randomness of testing, but also has a guiding nature, can efficiently trigger C / C++ library functions located at the bottom layer of the application, and effectively detect potential defects caused by parameter passing, state transition or cross-language calling; in addition, the method provides multiple testing strategies, which can be flexibly adapted to different testing targets and resource constraints, while ensuring that key functions and state transition paths are fully covered, significantly reducing redundant testing, and improving the level of testing automation and overall efficiency.
[0051] System embodiment According to the embodiment of the present application, a semi-random automatic testing system for Android native library is provided, Figure 3 A semi-random automatic testing system for Android native library provided for one or more embodiments of the present application is shown in the composition diagram, Figure 4 According to the embodiment of the present application, the semi-random automatic testing system for Android native library specifically includes: The list generation module is used to generate a native library function list with Android APK as input; The packaging module is used to convert the C / C++ code in the APK into Java bytecode and repack it to obtain a cross-language unified APK; The relationship graph construction module is used to construct a composite call relationship graph containing App state, UI and cross-language function call based on the cross-language unified APK; The event library generation module is used to generate a state transition event library according to the composite call relationship graph; The test case generation module is used to generate a test case pool based on the state transition event library using permutation and combination strategy; The test module is used to select test cases from the test case pool to perform semi-random automatic testing on Android native library functions.
[0052] The embodiment of the present application is a system embodiment corresponding to the above-mentioned method embodiment, and the specific operation of each module can be understood with reference to the description of the method embodiment, which will not be repeated here.
[0053] Device embodiment one The embodiment of the present application provides an electronic device, such as Figure 4 As shown in the figure, it comprises a memory 40, a processor 42, and a computer program stored on the memory 40 and executable on the processor 42, and the computer program is executed by the processor 42 to realize the following method steps: S1: taking an Android APK as input, generating a native library function list; S2: converting C / C++ code in the APK into Java bytecode and repackaging to obtain a cross-language unified APK; S3: based on the cross-language unified APK, constructing a composite call relationship graph containing App state, UI and cross-language function call; S4: according to the composite call relationship graph, guiding random testing to generate a state transition event library; S5: based on the state transition event library, generating a test case pool using permutation and combination strategy; S6: selecting test cases from the test case pool to perform semi-random automated testing on Android native library functions.
[0054] Device embodiment two The embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores an implementation program of information transmission, and the program is executed by a processor 32 to realize the following method steps: S1: taking an Android APK as input, generating a native library function list; S2: converting C / C++ code in the APK into Java bytecode and repackaging to obtain a cross-language unified APK; S3: based on the cross-language unified APK, constructing a composite call relationship graph containing App state, UI and cross-language function call; S4: according to the composite call relationship graph, guiding random testing to generate a state transition event library; S5: based on the state transition event library, generating a test case pool using permutation and combination strategy; S6: selecting test cases from the test case pool to perform semi-random automated testing on Android native library functions.
[0055] The computer readable storage medium described in the embodiment includes but is not limited to ROM, RAM, magnetic disk or optical disk, etc.
[0056] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions recorded in the above embodiments can be modified, or some or all of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.
Claims
1. A method for semi-random automated testing of Android native libraries, characterized in that, The method comprises the following steps: S1: taking an Android APK as input to generate a native library function list; S2: converting C / C++ code in the APK into Java bytecode and repackaging to obtain a cross-language unified APK; S3: based on the cross-language unified APK, a composite call relationship graph is constructed, which contains App state, UI and cross-language function calls; S4: according to the composite call relationship graph, random testing is guided to generate a state transition event library; S5: based on the state transition event library, a test case pool is generated using a permutation and combination strategy; S6: test cases are selected from the test case pool to perform semi-random automated testing on Android native library functions.
2. The method of claim 1, wherein, In S1, the function signature is extracted by reverse engineering and analyzing the dynamic link library file, and the function signature includes the function name, symbol and entry address to form the native library function list.
3. The method of claim 1, wherein, In S2, the C / C++ source code is converted into Java bytecode as a whole by a bytecode converter, and is repackaged with the original Java bytecode to form a cross-language unified APK.
4. The method of claim 1, wherein, S3 further comprises: The layout XML file is parsed to extract control identification, hierarchical relationship, geometric constraint and event listener binding information to form a structured UI description file; Based on the cross-language unified APK, a cross-language function call graph is constructed, which includes state functions and ordinary functions; The native library function list, cross-language function call graph and UI description file are associated and mapped to generate the composite call relationship graph.
5. The method according to claim 1, characterized in that S4 It comprises: A state transition event table is established for each adjacent (component, state) binary tuple in the composite call relationship graph; A probe log is inserted in the cross-language unified APK, a random event generation framework test is run and logs are collected, which include event information and probe trigger information; The minimum event sequence that contributes to state transition is extracted through log backtracking, written into the state transition event table to form the state transition event library.
6. The method of claim 5, wherein, The state transition event table contains: The event type field takes values including click, long press, swipe, keyboard input and sensor event; The input parameter field records coordinates, text, gesture trajectory or sensor values; The pre-state field and the post-state field record the (component, state) binary tuple before and after triggering, respectively.
7. The method of claim 1, wherein, The preset test strategy in S6 includes: Full strategy, function-oriented strategy, function coverage strategy, state coverage strategy and fast trigger strategy.
8. A semi-random automated testing system for Android native libraries, characterized in that, It comprises: A list generation module for taking an Android APK as input to generate a native library function list; A packaging module for converting C / C++ code in the APK into Java bytecode and repackaging to obtain a cross-language unified APK; A relationship graph construction module for constructing a composite call relationship graph based on the cross-language unified APK, which contains App state, UI and cross-language function calls; An event library generation module for generating a state transition event library according to the composite call relationship graph; A test case generation module for generating a test case pool using a permutation and combination strategy based on the state transition event library; Test module: for selecting test cases from the test case pool, performing semi-random automated testing on Android native library functions.
9. An electronic device, comprising: Comprising: a processor; and a memory arranged to store computer executable instructions that, when executed, cause the processor to implement the steps of the semi-random automated testing method for Android native libraries as claimed in any of claims 1 to 7.
10. A storage medium, characterized by a computer program product for storing computer executable instructions that, when executed, implement the steps of the semi-random automated testing method for Android native libraries as claimed in any of claims 1 to 7.