A testing method, apparatus, and equipment for application-based security interception.

Abstract

This invention discloses a testing method, apparatus, and device for application installation security interception. It relates to the field of mobile application security and automated testing. The method includes: obtaining a detection task for the installation package to be tested from a task queue; downloading the installation package to be tested to the local machine according to its download address; pushing the installation package to be tested to a specified storage path on the target Android device via an Android debugging bridge, and launching a pre-installed auxiliary application on the target Android device via the Android debugging bridge; operating the auxiliary application through a UI automated testing framework to trigger the installation of the installation package to be tested on the target Android device; obtaining the interface information of the target Android device during the installation process through the UI automated testing framework, and determining whether the installation is complete and whether security interception was triggered during the installation process based on the interface information; if the installation is complete, generating a structured test report. This invention enables automated and proactive detection of application installation security risks.

Description

Technical Field

[0001] This invention relates to the field of mobile application security and automated testing technology, and in particular to a testing method, apparatus and equipment for application installation security interception. Background Technology

[0002] During the distribution of Android applications, especially when installed through unofficial app store channels, the mobile operating system or security services (such as Google Play Protect) trigger a security scan mechanism. This mechanism assesses the security of the application installation package to be installed, which may result in time-consuming waits or security warnings during the installation process.

[0003] Currently, in multi-channel distribution scenarios, different channel packages of the same application function, due to their different file characteristics (such as MD5 values), are treated as independent application packages by the system and subjected to repeated security scans. This situation presents the following problems: User experience and retention issues: Each new file-specific installation package triggers a full scan and wait on the user's side, prolonging the installation time, increasing the probability of users abandoning the installation, and causing user churn.

[0004] Issues with proactive security and brand risk detection: Security risk warnings (such as those marked "risk exists") are only triggered for the first time during the application's installation phase by real users, resulting in a delay in risk detection. Developers may find it difficult to be aware of and address these risks in a timely manner, potentially leading to the spread of negative impacts.

[0005] Therefore, a technical solution is needed that can automatically and in batches simulate the real user installation environment before application distribution, trigger security scans in advance, and accurately identify scan results to address the problems of repeated scanning and delayed risk detection. Summary of the Invention

[0006] This invention provides a testing method, apparatus, and device for application installation security interception, which solves the problem in the prior art that it is impossible to automatically and in batches simulate the real user installation path to trigger and identify system security scan results before application release, thus causing repeated waiting during the user installation stage and delayed discovery of security risks.

[0007] According to one aspect of the present invention, a test method for application installation security interception is provided, executed by a control terminal, comprising: Retrieve the test task for the installation package to be tested from the task queue, and download the installation package to be tested to the local machine according to the download address of the installation package to be tested; The test installation package is pushed to a specified storage path of the target Android device through the Android debugging bridge, and a pre-installed auxiliary application on the target Android device is launched through the Android debugging bridge; The auxiliary application is operated through a UI automation testing framework to trigger the installation of the installation package under test on the target Android device; The UI automation testing framework obtains the interface information of the target Android device during the installation process, and determines whether the installation is complete and whether security interception is triggered during the installation process based on the interface information. If the installation is complete, a structured test report will be generated; the test report includes the feature identifier of the installation package under test, the installation result, whether security interception was triggered, and the type of pop-up window triggered.

[0008] According to another aspect of the present invention, a test device for application installation security interception is provided, applied to a control terminal, comprising: The installation package download module is used to obtain the detection task of the installation package to be tested from the task queue, and download the installation package to be tested to the local machine according to the download address of the installation package to be tested; An auxiliary application launch module is used to push the installation package to be tested to a specified storage path of the target Android device through the Android debugging bridge, and launch the pre-installed auxiliary application on the target Android device through the Android debugging bridge. The installation trigger module is used to operate the auxiliary application through the UI automation testing framework to trigger the installation of the installation package to be tested on the target Android device; The installation process monitoring module is used to obtain the interface information of the target Android device during the installation process through the UI automation testing framework, and to determine whether the installation is complete and whether security interception is triggered during the installation process based on the interface information. The test report generation module is used to generate a structured test report if the installation is completed. The test report includes the feature identifier of the installation package under test, the installation result, whether security interception is triggered, and the type of pop-up window triggered.

[0009] According to another aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the application installation security interception test method according to any embodiment of the present invention.

[0010] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the application installation security interception test method according to any embodiment of the present invention.

[0011] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the test method for application installation security interception as described in any embodiment of the present invention.

[0012] According to another aspect of the present invention, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement a test method for application installation security interception as described in any embodiment of the present invention.

[0013] This invention, by simulating the complete installation process of a real user, automatically triggers and captures responses from system security mechanisms (such as Google Play Protect), achieving batch and efficient pre-emptive detection of installation compatibility and security risks before application distribution. By deploying the installation package under test to a real device environment and driving an auxiliary application to call the standard Android system installation process, it ensures that the security scanning logic is consistent with that on the user side. A UI automation framework is used to monitor and intelligently parse the installation interface in real time, automatically identifying successful installations, failures, and various security warning pop-ups. A structured test report is generated and bound to the installation package characteristics, forming a reusable security knowledge base. This solves the problem that in actual business scenarios, some Android system security scanning mechanisms primarily use the unique characteristics of Android application installation packages (such as MD5 values) as the identification dimension. This leads to a large number of Android application installation packages with different MD5 values ​​but identical functions, resulting in duplicate scanning due to changes in installation package characteristics, especially in multi-channel distribution scenarios. Furthermore, it enables early detection and interception of security risks, avoiding the problem that risk information is only triggered during the real user installation stage, making timely recovery and processing difficult, and resulting in delayed detection and expanded impact. Reduce the risk of user churn and identify potential security and brand risks in advance.

[0014] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of a test method for application installation security interception provided by an embodiment of the present invention; Figure 2 This is a flowchart of a test method for application installation security interception provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a test device for application installation security interception provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the test method for application installation security interception according to embodiments of the present invention. Detailed Implementation

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

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. 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 comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] Figure 1 This is a flowchart of a testing method for application installation security interception provided by an embodiment of the present invention. This embodiment is applicable to situations requiring automated and batch pre-testing of the installation compatibility and security of Android application installation packages in real user scenarios. This method can be executed by an application installation security interception testing device, which can be implemented in hardware and / or software. This device can be configured in an electronic device with corresponding data processing capabilities, such as a control server. Figure 1 As shown, the method includes: S110. Obtain the test task of the installation package to be tested from the task queue, and download the installation package to be tested to the local machine according to the download address of the installation package to be tested.

[0020] In mobile application distribution, especially in overseas markets, applications need to be distributed through multiple channels, including official app stores, third-party app stores, direct downloads, and pre-installation by partners. To ensure the compatibility and security of the application across these channels, the developer or distribution platform must generate a corresponding application installation package (APK) for each independent channel before release, i.e., a channel package. Although the functions of each channel package are the same, the fingerprint characteristics of the channel package files are also different because they contain different channel identification information.

[0021] The upstream system refers to the application building and distribution system that interfaces with the testing methods for application installation security interception, and is used to generate detection task instructions and / or receive and process test results. After the upstream system completes the construction of a new channel package, it submits a detection task containing information about that channel package to the task queue. The control terminal obtains the detection task from the task queue through polling or subscription. The detection task is structured data, and includes at least a task identifier, the download address of the installation package to be tested, the channel identifier, and the application version number.

[0022] Based on the download address of the installation package to be tested, the package is downloaded from the remote file server to local storage via HTTP or HTTPS protocol. The download process can employ breakpoint resumption and error retry mechanisms to ensure reliability. After downloading, the control terminal can optionally perform integrity verification on the installation package and calculate its unique identifier (such as MD5 or SHA-256 hash value). This identifier will serve as the core basis for associating and identifying the installation package in subsequent processes. The integrity of the installation package to be tested is verified (e.g., file size threshold, optional zip structure verification).

[0023] Understandably, by retrieving the test task of the installation package to be tested from the task queue and downloading the installation package to be tested to the local machine according to the download address of the installation package to be tested, the automated acquisition and preparation of test tasks and test objects are realized. This provides the necessary input for simulating user installation behavior in a real device environment and lays the material foundation for the automated testing process.

[0024] S120: Push the installation package to be tested to the specified storage path of the target Android device through the Android debugging bridge, and start the pre-installed auxiliary application on the target Android device through the Android debugging bridge.

[0025] The target Android device refers to the Android terminal that serves as the execution environment during the testing process. This device is pre-installed with complete Google Mobile Services and is in a debuggable state, used to carry out the actual installation process of the installation package under test to trigger system security scans. The auxiliary application refers to a lightweight Android program pre-installed on the target Android device. Its core function is to respond to external commands, construct and launch the system's standard application installation intent based on a specified file path, thus acting as a bridge to convert automated operations from the control end into calls to the system's native package installer components.

[0026] Specifically, a usable target Android device is selected from the device resource pool. This pool consists of multiple pre-configured Android test devices running the full Google Mobile Services (GMS). Each device is powered on, unlocked, and in developer mode (USB debugging enabled), maintaining a stable connection to the control terminal via USB or network ADB (Android Debug Bridge). Based on preset strategies (such as device idle status and system version compatibility), an idle device is selected, its status is marked as "occupied," and an independent ADB session connection is established.

[0027] The Android debug bridge's `push` command is invoked to transfer the downloaded installation package to the target Android device's preset storage path, and the file's existence is verified a second time. The preset storage path is usually set to the device's external storage public download directory (e.g., ` / sdcard / Download / `) to simulate the storage state of a real user downloading an application package from the network.

[0028] The Android debug bridge's shell am start command sends an application launch command to the target Android device, launching an auxiliary application that has been pre-installed on the target Android device.

[0029] S130. Operate the auxiliary application through the UI automation testing framework to trigger the installation of the test package on the target Android device.

[0030] By using a UI automation testing framework (such as UIAutomator2 or Appium) to operate an auxiliary application, the auxiliary application can automatically invoke the system's standard installation process based on a specified storage path, thereby activating the package installer interface of the target Android device and loading the installation package to be tested. Using the same UI automation testing framework, the installation operation is located and triggered within the package installer interface, causing the target Android device to begin the installation process.

[0031] Optionally, an auxiliary application is operated through a UI automation testing framework to trigger the installation of the test package on the target Android device. This includes: using the UI automation testing framework to locate the installation trigger control based on the control attributes of the auxiliary application interface, and simulating a click operation on the installation trigger control, so that the auxiliary application generates and launches a standard intent object for calling the package installer based on a specified storage path; wherein, the launch of the intent object will invoke the package installer interface of the target Android device and load the test package into the package installer interface; using the UI automation testing framework to locate the installation confirmation trigger control based on the control attributes of the package installer interface, and simulating a click operation on the installation confirmation trigger control, so that the target Android device executes the installation operation of the test package.

[0032] Using a UI automation testing framework (such as UIAutomator2 or Appium), the UI hierarchy of the current interface of the auxiliary application is parsed. Based on preset control recognition rules (such as matching specific text or resource IDs), the installation trigger control of the auxiliary application (e.g., an "Install" or "Open" button) is located. A simulated click command is then sent to the installation trigger control through the UI automation testing framework to trigger a click operation on the installation trigger control.

[0033] In response to the click, the accessibility app constructs a standard Android ACTION_VIEW type intent object locally, based on the installation package to be tested pushed to the specified storage path of the target Android device. This intent object contains a URI pointing to the installation package to be tested and sets its MIME type to application installation package type. The accessibility app calls the system interface to launch this intent object. The launch of this intent object will be interpreted by the Android system as a request to open an application installation package. The Android system then calls and displays the system's default package installer component in the foreground, and loads the installation package to be tested into the package installer interface, thus completing the triggering of the standard system installation process from the accessibility app. At this point, the system package installer interface is ready and enters the state of waiting for user confirmation of installation.

[0034] After the installer interface is successfully displayed, a UI automation testing framework is used to parse the UI hierarchy of the installer interface and locate the installation confirmation trigger control (e.g., a "Confirm Install" button) based on preset control recognition rules (such as matching specific text or resource IDs). A simulated click command is then sent to this installation confirmation trigger control via the UI automation testing framework, triggering a click operation on the control. A confirmation installation command is then submitted to the Android system, causing the Android system to begin the actual application installation process, thus entering the installation execution phase that may trigger security interception.

[0035] By performing two precise, UI control-based automated click operations, a complete chain is connected from the auxiliary application call to the system installer response, highly replicating the entire path of a real user manually installing an application, ensuring that the system-level security scanning mechanism can be reliably and consistently triggered.

[0036] S140. Obtain the interface information of the target Android device during the installation process through the UI automation testing framework, and determine whether the installation is complete and whether security interception is triggered during the installation process based on the interface information.

[0037] A UI automation testing framework is used to acquire interface information of the target Android device during the installation process, enabling status monitoring of the target Android device's foreground interface. Specifically, based on the acquired interface information, a status determination is made to determine whether the installation is complete, with the result including successful or failed installation. Before installation is complete, it is determined whether any security interceptions are triggered during the installation process. Status monitoring continues until installation is complete.

[0038] In one specific implementation, the status monitoring is achieved by periodically sampling the interface information of the target Android device. During each sampling, the interface of the UI automation testing framework is invoked to obtain structured description information of the current interface of the target Android device (such as a snapshot of the UI control hierarchy). Status determination is performed by parsing the description information and matching it with predefined status feature rules. For example, the installation result can be determined by identifying whether the interface contains specific text indicating "installation successful" or "installation failed"; simultaneously, by identifying whether pop-up controls containing specific security keywords (such as "Google Play Protect," "scan," or "harmful") appear, it can be determined whether a security interception event has been triggered, and the specific risk type of the pop-up control can be further distinguished based on the text content in the pop-up.

[0039] S150. If the installation is complete, a structured test report is generated. The test report includes the feature identifier of the installation package under test, the installation result, whether security interception is triggered, and the type of pop-up window triggered.

[0040] When the installation is deemed complete (whether successful or failed), a structured test report is generated by integrating key data generated during the task execution. The test report includes the identifier of the installation package under test, the installation result, whether security interception was triggered, and the type of pop-up window triggered. The identifier is a unique feature code of the installation package under test, such as an MD5 or SHA-256 hash value, used to accurately identify the tested object. The installation result is an enumerated value representing the installation status, typically "success" or "failure." Whether security interception was triggered is a Boolean value, recording whether any risk warnings or blocks initiated by security components (such as Google Play Protect) occurred during the installation process. The type of pop-up window triggered records the specific type if security interception was triggered, such as "security scan prompt," "harmful application warning," or "unknown risk pop-up," etc.; if not triggered, this field can be empty or marked as "none."

[0041] Test reports are stored in a database or returned to upstream systems. In continuous integration / continuous delivery pipelines, test reports serve as quality gates. If a report indicates that a certain channel package will trigger a "harmful" high-risk interception, the pipeline can automatically block the release of that version and notify developers to fix it, preventing risks from reaching users at the source. A mapping relationship is established between the feature identifiers in the test reports and whether security interceptions are triggered. When installation packages with the same feature identifiers (such as unchanged parent packages or packages from the same channel) are distributed again, automated testing systems or distribution platforms can prioritize querying test reports. If the test report records that the feature identifier "no interception triggered" or "security scanned," then when pushing installations to real users, real-time scanning can be skipped or waiting time significantly shortened during the installation process, thereby improving installation success rate and user experience. Furthermore, through batch analysis of historical test reports, application characteristics that are prone to triggering specific types of security interceptions (such as the use of third-party SDKs, specific code patterns, or signature methods) can be identified. This provides reverse guidance to development and compliance teams to optimize application building strategies and systematically reduce security risks in future versions.

[0042] In one alternative implementation, the method further includes: uninstalling application instances already installed on the target Android device by the test installation package via an Android debugging bridge, deleting the installation package file stored in a specified storage path, and resetting the interface and status of the target Android device to an idle and available state.

[0043] A series of cleanup commands are sent to the target Android device via the Android debugging bridge. If the test installation package is successfully installed in this test, an application uninstallation command is sent to remove the existing instance of the application on the target Android device. A file deletion command is sent to clear the installation package file pushed to the specified storage path on the target Android device to prevent residual files from occupying storage space or interfering with subsequent tests. Device state restoration operations are performed, including but not limited to: forcibly exiting any potentially residual foreground application interfaces, clearing temporary data related to this test, and remarking the target Android device's state as "idle" in the resource management pool.

[0044] By uninstalling application instances already installed on the target Android device from the installation package to be tested, deleting the installation package files stored in the specified storage path, and resetting the interface and status of the target Android device to an idle and available state, the target Android device is restored to a clean and standard initial state, which can be immediately scheduled to execute the next testing task. This achieves efficient recycling of the testing equipment and supports the batch and automated execution of the method of this invention.

[0045] This invention, by simulating the complete installation process of a real user, automatically triggers and captures responses from system security mechanisms (such as Google Play Protect), achieving batch and efficient pre-emptive detection of installation compatibility and security risks before application distribution. By deploying the installation package under test to a real device environment and driving an auxiliary application to call the standard Android system installation process, it ensures that the security scanning logic is consistent with that on the user side. A UI automation framework is used to monitor and intelligently parse the installation interface in real time, automatically identifying successful installations, failures, and various security warning pop-ups. A structured test report is generated and bound to the installation package characteristics, forming a reusable security knowledge base. This solves the problem that in actual business scenarios, some Android system security scanning mechanisms primarily use the unique characteristics of Android application installation packages (such as MD5 values) as the identification dimension. This leads to a large number of Android application installation packages with different MD5 values ​​but identical functions, resulting in duplicate scanning due to changes in installation package characteristics, especially in multi-channel distribution scenarios. Furthermore, it enables early detection and interception of security risks, avoiding the problem that risk information is only triggered during the real user installation stage, making timely recovery and processing difficult, and resulting in delayed detection and expanded impact. Reduce the risk of user churn and identify potential security and brand risks in advance.

[0046] Figure 2 This is a flowchart of a testing method for application installation security interception provided by an embodiment of the present invention. This embodiment optimizes and improves the process described above by "obtaining the interface information of the target Android device during the installation process through a UI automation testing framework, determining whether the installation is complete based on the interface information, and whether security interception was triggered during the installation process." Figure 2 As shown, the method includes: S210. Obtain the test task of the installation package to be tested from the task queue, and download the installation package to be tested to the local machine according to the download address of the installation package to be tested.

[0047] S220: Push the installation package to be tested to the specified storage path of the target Android device through the Android debugging bridge, and start the pre-installed auxiliary application on the target Android device through the Android debugging bridge.

[0048] S230: Operate the auxiliary application through the UI automation testing framework to trigger the installation of the test package on the target Android device.

[0049] S240. Obtain a snapshot of the current foreground interface hierarchy of the target Android device through a UI automation testing framework.

[0050] S250. If a risk warning control from a security component is identified based on the interface hierarchy snapshot, a security interception is triggered. The pop-up type is determined based on the characteristics of the control, and a preset response operation corresponding to the pop-up type is executed through the UI automation testing framework.

[0051] The snapshot of the target Android device's current foreground interface hierarchy is presented in a structured data format (such as an XML-formatted control tree), containing the attributes, text content, hierarchical relationships, and state information of all visible controls on the current interface. After the installation process of the installation package under test begins, the control terminal, through a UI automation testing framework, periodically initiates sampling of the target Android device's foreground interface at preset time intervals. Each sampling obtains a snapshot of the target Android device's current foreground interface hierarchy through the UI automation testing framework's interface. This periodic sampling process continues until installation is complete.

[0052] Risk warning controls are specific UI elements dynamically generated and displayed by security components (such as Google Play Protect) when an installation package is determined to pose a potential risk. They typically appear as pop-ups, designed to alert or request user interaction. To clearly convey risk information, security components use specific keywords in the title, body, or button of the risk warning control. These include component identifiers (such as "Google Play Protect"), behavioral descriptions (such as "scan," "check"), risk conclusions stating the assessment results (such as "harmful," "malicious," "dangerous"), and suggested actions (such as "block," "learn more"). Risk warning controls can be identified by matching text nodes in a snapshot of the UI hierarchy with predefined keywords.

[0053] If a risk warning control is identified, it is determined that the installation has triggered a security block. After confirming the security block, the pop-up type is determined based on the text content characteristics of the risk warning control, such as "scanning," "security check," "harmful warning," or "unknown pop-up." Using the UI automation testing framework, a preset response operation strictly bound to this pop-up type is executed. This response operation is pre-programmed to simulate the interaction behavior a real user would take when faced with this type of pop-up (e.g., clicking the "scan" button, clicking "don't send," or clicking "learn more" and "install anyway," or taking a screenshot as evidence and confirming installation failure). The aim is to either allow the installation process to continue under the current security warning or terminate the installation according to a preset strategy. For scanning pop-ups, click "Scan Application" and wait for the scan results. If the scan is safe, click "Install" to continue. If a harmful / malicious warning is displayed, proceed to view details / install still. For security check pop-ups, click "Don't Send" to continue with the installation process. For harmful warning pop-ups, click view details / install still or directly block the installation, resulting in installation failure. For unknown pop-ups, take a screenshot as evidence and handle as failed / abnormal, resulting in installation failure.

[0054] After executing the preset response operation, periodic interface monitoring will continue. The UI automation testing framework will be used to obtain a snapshot of the current foreground interface hierarchy of the target Android device to obtain the Android system's handling result of this operation (such as whether the pop-up window disappears or whether a new scan result interface appears) and the subsequent progress of the installation process until the installation is completed.

[0055] Optionally, the pop-up type can be determined based on the characteristics of the control, and a preset response operation corresponding to the pop-up type can be executed through the UI automation testing framework, including: if it is a scanning pop-up, the UI automation testing framework can be used to locate and click the scan confirmation control, and wait for the scan results; if it is a security check pop-up, the UI automation testing framework can be used to locate and click the control not to send or ignore it; if it is a harmful warning pop-up, the UI automation testing framework can be used to locate and click the options to view details and still install the control.

[0056] If the pop-up is identified as a scanning pop-up, the UI automation testing framework will locate and simulate clicking the scan confirmation control (such as the "Scan" button) on the pop-up. After clicking, the control terminal will enter a waiting state, monitoring the interface changes of the target Android device to capture the result interface after the scan is completed.

[0057] If the pop-up is identified as a security check, the UI automation testing framework is used to locate and simulate clicking on controls such as "Don't send" or "Ignore" on the pop-up to minimize data reporting and eliminate the pop-up.

[0058] If a pop-up window is identified as a harmful warning, the UI automation testing framework is used to locate and simulate clicking the "More Details" or "Learn More" control on the pop-up window. In the expanded details interface, the "Install Still" or similar control is located and simulated to force the installation process.

[0059] By using pre-defined strategic branches, the system automates and differentiates the handling of various known security pop-ups, ensuring that the automated installation process can effectively cope with complex interaction scenarios.

[0060] Optionally, installation completion includes successful installation or installation failure. The determination of whether the installation is complete is based on the interface information, including: if the interface features indicating successful installation are identified based on the interface layer snapshot, the installation is determined to be successful; if the interface features indicating installation failure are identified based on the interface layer snapshot and no risk warning control is identified at the same time, the installation is determined to be failed; if the interface features indicating that the installation is in progress are identified based on the interface layer snapshot, the installation is determined to be incomplete. After a preset time interval, the UI automation testing framework obtains the current foreground interface layer snapshot of the target Android device.

[0061] If specific interface features indicating successful installation are identified in the interface-level snapshot (e.g., system prompts containing text such as "Application installed" or "Completed"), the installation is determined to have been successfully completed. If interface features indicating installation failure are identified in the interface-level snapshot (e.g., prompts containing text such as "Application not installed" or "Installation failed"), and no risk warning controls from security components are identified, the installation is determined to have failed. If interface features indicating that installation is in progress are identified in the interface-level snapshot (e.g., an installation progress bar is displayed, or dynamic text such as "Installing"), the installation process is determined to be incomplete. In this case, the control terminal will wait for a preset time interval before obtaining a new interface-level snapshot for the next round of status determination. This cycle will continue until the installation is complete (installation successful or installation failed).

[0062] By introducing state machine decision logic based on interface features, all possible exits (success, failure) and intermediate states (in progress) of the installation process can be clearly and unambiguously defined, and security interception events are clearly treated as high-priority interruptions and handled separately. This ensures that the automated monitoring loop has clear termination conditions and loop rules, thereby achieving reliable tracking and intelligent decision-making for complex installation processes, and guaranteeing the accuracy of test conclusions and the robustness of the process.

[0063] S260. If the installation is complete, a structured test report will be generated. The test report includes the characteristics of the installation package under test, the installation result, whether security interception was triggered, and the type of pop-up window triggered.

[0064] This invention, through its embodiments, automatically triggers system-level security scans in a controlled environment by simulating the complete installation path of a real user (from file deployment to interface clicks). It utilizes continuous status monitoring based on UI snapshots and intelligent rule-based judgment to achieve fully automated identification and categorized response to key events such as successful installation, installation failure, and security interception. By generating a structured report that associates installation package characteristics, final results, and security risk details, a reusable security knowledge base is constructed. This allows for the early detection and resolution of risks before application distribution, effectively addressing the industry pain points of time-consuming repetitive scans caused by changes in installation package characteristics and delayed security risk discovery.

[0065] Figure 3 This is a schematic diagram of the structure of a test device for application installation security interception provided in an embodiment of the present invention. Figure 3 As shown, this device is used in the control terminal and includes: The installation package download module 310 is used to obtain the detection task of the installation package to be tested from the task queue and download the installation package to be tested to the local machine according to the download address of the installation package to be tested; The auxiliary application launch module 320 is used to push the installation package to be tested to a specified storage path of the target Android device through the Android debugging bridge, and launch the pre-installed auxiliary application on the target Android device through the Android debugging bridge; Install trigger module 330, which is used to operate the auxiliary application through the UI automation testing framework to trigger the installation of the installation package to be tested on the target Android device; The installation process monitoring module 340 is used to obtain the interface information of the target Android device during the installation process through the UI automation testing framework, and to determine whether the installation is complete and whether security interception is triggered during the installation process based on the interface information. The test report generation module 350 is used to generate a structured test report if the installation is completed. The test report includes the characteristic identifier of the installation package under test, the installation result, whether security interception is triggered, and the type of pop-up window triggered.

[0066] The application installation security interception test device provided in the embodiments of the present invention can execute the application installation security interception test method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0067] Optional, the installation process monitoring module includes: The interface information acquisition unit is used to obtain a snapshot of the current foreground interface hierarchy of the target Android device through the UI automation testing framework; The security interception judgment unit is used to determine that if a risk warning control from a security component is identified based on the interface hierarchy snapshot, security interception is triggered. The pop-up type is determined based on the characteristics of the control, and a preset response operation corresponding to the pop-up type is executed through the UI automation testing framework.

[0068] Optionally, a security interception judgment unit is used to locate and click the scan confirmation control through the UI automation testing framework if it is a scanning pop-up, and wait for the scan results; if it is a security check pop-up, locate and click the control not to send or ignore it through the UI automation testing framework; if it is a harmful warning pop-up, locate and click the control to view details and still install it through the UI automation testing framework.

[0069] Optionally, the installation completion includes whether the installation was successful or failed. The installation process monitoring module includes an installation status judgment unit. The installation status judgment unit is used to determine that the installation is successful if it identifies interface features indicating successful installation based on the interface layer snapshot; if it identifies interface features indicating failed installation based on the interface layer snapshot and does not simultaneously identify a risk warning control, it determines that the installation has failed; if it identifies interface features indicating that the installation is in progress based on the interface layer snapshot, it determines that the installation is incomplete. After a preset time interval, it obtains the current foreground interface layer snapshot of the target Android device through a UI automation testing framework.

[0070] Optional, install a trigger module, including: The intent object generation unit is used to locate the installation trigger control based on the control attributes of the auxiliary application interface through the UI automation testing framework, and simulate the click operation of the installation trigger control so that the auxiliary application generates and launches a standard intent object for calling the package installer based on the specified storage path; the launch of the intent object will bring up the package installer interface of the target Android device and load the installation package to be tested into the package installer interface. The installation execution unit is used to locate the installation confirmation trigger control based on the control properties of the package installer interface through a UI automation testing framework, and simulate the click operation of the installation confirmation trigger control so that the target Android device executes the installation operation of the package under test.

[0071] Optionally, it also includes: a test report generation module, which is used to uninstall application instances already installed on the target Android device by the test installation package through the Android debugging bridge, delete the installation package files stored in the specified storage path, and reset the interface and status of the target Android device to an idle and available state.

[0072] The application installation security interception test device, which is further explained, can also execute the application installation security interception test method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0073] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product.

[0074] Figure 4A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0075] like Figure 4 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory 42 or a random access memory 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 42 or loaded from storage unit 48 into the random access memory 43. The random access memory 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, read-only memory 42, and random access memory 43 are interconnected via a bus 44. An input / output interface 45 is also connected to the bus 44.

[0076] Multiple components in electronic device 40 are connected to input / output interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0077] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as application installation security interception test methods.

[0078] In some embodiments, the application installation security interception test method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 40 via read-only memory 42 and / or communication unit 49. When the computer program is loaded into random access memory 43 and executed by processor 41, one or more steps of the application installation security interception test method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to perform the application installation security interception test method by any other suitable means (e.g., by means of firmware).

[0079] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), systems-on-a-chip (SoCs), payload programmable logic devices, computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0080] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0081] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0082] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube, liquid crystal display, or monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0083] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0084] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.

[0085] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0086] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A test method for application installation security interception, characterized in that, Executed by the control terminal, the method includes: Retrieve the test task for the installation package to be tested from the task queue, and download the installation package to be tested to the local machine according to the download address of the installation package to be tested; The test installation package is pushed to a specified storage path of the target Android device through the Android debugging bridge, and a pre-installed auxiliary application on the target Android device is launched through the Android debugging bridge; The auxiliary application is operated through a UI automation testing framework to trigger the installation of the installation package under test on the target Android device; The UI automation testing framework obtains the interface information of the target Android device during the installation process, and determines whether the installation is complete and whether security interception is triggered during the installation process based on the interface information. If the installation is complete, a structured test report will be generated; the test report includes the feature identifier of the installation package under test, the installation result, whether security interception was triggered, and the type of pop-up window triggered.

2. The method according to claim 1, characterized in that, The process of obtaining the target Android device's interface information during installation through the UI automation testing framework, and determining whether the installation is complete based on the interface information, as well as whether security interception is triggered during the installation process, includes: The UI automation testing framework is used to obtain a snapshot of the current foreground interface hierarchy of the target Android device. If a risk warning control from a security component is identified based on the interface layer snapshot, a security interception is triggered. The pop-up type is determined based on the characteristics of the control, and a preset response operation corresponding to the pop-up type is executed through the UI automation testing framework. After a preset time interval, the UI automation testing framework obtains a snapshot of the current foreground interface layer of the target Android device.

3. The method according to claim 2, characterized in that, The step of determining the pop-up type based on the characteristics of the control and executing a preset response operation corresponding to the pop-up type through the UI automation testing framework includes: If it is a scan-related pop-up, locate and click the scan confirmation control using the UI automation testing framework, and wait for the scan results; If it is a security check pop-up, locate it using the UI automation testing framework and click "Do not send" or "Ignore control". If the pop-up is a harmful warning, locate it sequentially using the UI automation testing framework and click to view details and then select "Still need to install controls".

4. The method according to claim 2, characterized in that, Installation completion includes both successful and failed installation. The step of determining whether installation is complete based on the interface information includes: If the interface features indicating successful installation are identified based on the interface hierarchy snapshot, then the installation is determined to be successful. If, based on the interface hierarchy snapshot, an interface feature indicating installation failure is identified but no risk warning control is identified at the same time, then the installation is determined to have failed. If, based on the interface hierarchy snapshot, interface features indicating that installation is in progress are identified, then it is determined that the installation is incomplete. After a preset time interval, the UI automation testing framework obtains the current foreground interface hierarchy snapshot of the target Android device.

5. The method according to claim 1, characterized in that, The step of operating the auxiliary application through a UI automation testing framework to trigger the installation of the test package on the target Android device includes: Using the UI automation testing framework, the installation trigger control is located based on the control attributes of the auxiliary application interface, and a click operation on the installation trigger control is simulated, so that the auxiliary application generates and launches a standard intent object for calling the package installer based on the specified storage path; the launch of the intent object will bring up the package installer interface of the target Android device and load the installation package to be tested into the package installer interface. Using the UI automation testing framework, the installation confirmation trigger control is located based on the control attributes of the package installer interface, and a click operation on the installation confirmation trigger control is simulated to make the target Android device execute the installation operation of the package under test.

6. The method according to claim 1, characterized in that, The method further includes: The Android debugging bridge uninstalls the application instances already installed on the target Android device by the installation package under test, deletes the installation package files stored in the specified storage path, and resets the interface and status of the target Android device to an idle and available state.

7. A testing device for applying security interception, characterized in that, The device, applied to the control terminal, includes: The installation package download module is used to obtain the detection task of the installation package to be tested from the task queue, and download the installation package to be tested to the local machine according to the download address of the installation package to be tested; An auxiliary application launch module is used to push the installation package to be tested to a specified storage path of the target Android device through the Android debugging bridge, and launch the pre-installed auxiliary application on the target Android device through the Android debugging bridge. The installation trigger module is used to operate the auxiliary application through the UI automation testing framework to trigger the installation of the installation package to be tested on the target Android device; The installation process monitoring module is used to obtain the interface information of the target Android device during the installation process through the UI automation testing framework, and to determine whether the installation is complete and whether security interception is triggered during the installation process based on the interface information. The test report generation module is used to generate a structured test report if the installation is completed. The test report includes the feature identifier of the installation package under test, the installation result, whether security interception is triggered, and the type of pop-up window triggered.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then executed by the at least one processor to enable the at least one processor to perform the test method for application installation security interception as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the test method for application installation security interception as described in any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements a test method for application installation security interception according to any one of claims 1-6.

Images