Cloud phone environment initialization system based on android debug bridge command

Abstract

This invention provides a cloud phone environment initialization system based on Android debug bridge commands. From the generation of three types of request parameters, to the integration and optimization of parameter set aggregation and verification, and finally to the implementation and activation of the ADB-based execution engine, the entire process forms a closed loop: "source parameter generation → multi-source integration → compliance verification → secure execution → instance output." This mechanism ensures high simulation accuracy of parameters (closely resembling real devices and environments), resolves conflicts between multi-source parameters through aggregation and verification, and ultimately achieves efficient, secure, and batch initialization of the cloud phone environment through the atomic operations of the ADB execution engine, providing core technical support for scenarios such as automated testing and marketing operations.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and mobile application technology, and in particular to a cloud phone environment initialization system based on Android Debug Bridge (ADB) commands. Background Technology

[0002] With the rapid development of cloud computing and mobile application services, cloud phones, as virtual mobile devices based on cloud computing technology, are widely used in various fields such as automated testing, application compatibility analysis, social media marketing, and e-commerce operations. In these scenarios, businesses typically need to run cloud phone instances on a large scale and in batches to meet their business requirements.

[0003] However, conventional cloud phone instances are typically configured with fixed and uniform device parameters at the factory, including key information such as brand, model, serial number, MEI, and system version. When a large number of cloud phone instances with the same or similar device fingerprints simultaneously access a certain application or service, they are easily identified as abnormal behavior by the target platform's risk control system, leading to account restrictions, bans, or business interruptions, severely impacting business continuity.

[0004] Currently, modifying cloud phone device parameters to mitigate the aforementioned risks presents numerous technical challenges: First, the technical threshold is high; modifying underlying system parameters requires a deep understanding of the Android system and root access, making the operation complex and risky, difficult for ordinary users to master. Second, manual operation is cumbersome; manually modifying numerous parameters of individual devices is time-consuming and labor-intensive, completely failing to meet the batch processing needs of large-scale businesses. Third, parameters are highly correlated; complex logical relationships exist between device parameters (such as the need for matching brand, model, motherboard, and system version number), making manual modification prone to errors, resulting in an unrealistic device environment that is more easily identified by risk control systems. Furthermore, there is a lack of systematic solutions; the market lacks a simple, efficient, batch-based "one-click new device" solution that highly simulates real devices, failing to meet the business's needs for differentiated device environments and security.

[0005] Therefore, there is an urgent need for a technical solution that can solve the above problems and achieve efficient, batch, and highly realistic initialization of cloud phone environments. Summary of the Invention

[0006] This invention aims to address the problems of high technical barriers, cumbersome manual operation, easy parameter conflicts, and lack of systematic solutions in the modification of cloud mobile device parameters in the prior art. It provides a cloud mobile environment initialization system based on Android debug bridge commands, which realizes rapid, batch, and highly realistic initialization of the cloud mobile environment, effectively avoids risk control detection, and ensures stable business operation.

[0007] Specifically, this invention provides a cloud phone environment initialization system based on Android debug bridge commands, comprising: an input layer containing cloud phone dynamic information, a built-in device parameter library, an external clone configuration file, and user requests introduced by business API call entry points; and a system core processor comprising an instruction unified parsing module, a parameter set aggregation and verification module, a parameter source intelligent selection and verification module, and an execution engine. User requests are parsed by the instruction unified parsing module to form internal instructions, which are then passed to the parameter source intelligent selection and verification module. Cloud phone dynamic information, as a parameter source, matches the internal instructions and outputs an environment simulation request type from the parameter source intelligent selection and verification module. The built-in device parameter library, as a parameter source, outputs a device selection request type from the parameter source intelligent selection and verification module. The external clone configuration file serves as a parameter source. The data source intelligent selection and verification module outputs the clone replication request type; the decision and generation module takes the environment simulation request type as input, and the dynamic parameter generator is invoked and input with the cloud phone's dynamic information to adapt to the environment simulation request type, forming a dynamic simulation parameter set; the device selection request type is input to the decision and generation module and located to the built-in device parameter library, from which static source parameters are extracted; the clone replication request type is input to the decision and generation module, and based on this type, the external clone configuration file is parsed to extract external source parameters; the parameter set aggregation and verification module merges the dynamic simulation parameter set, static source parameters, and external source parameters into a composite parameter set. After verification in the parameter set aggregation and verification module, the composite parameter set forms a compliant parameter set, which is then written to the cloud phone instance after ADB debugging in the execution engine.

[0008] Preferably, the dynamic information of the cloud phone includes the current IP address of the cloud phone, the geographical location specified by the user, and the network type.

[0009] Preferably, the built-in device parameter library stores the static parameters of multiple real devices.

[0010] Preferably, the external clone configuration file is a complete parameter snapshot of the real device uploaded by the user.

[0011] Preferably, the user request comes from a third-party business system and is in the form of a structured request conforming to the OpenAPI specification.

[0012] Preferably, the device selection request type includes three subtypes: specified model request, specified brand request, and random model request.

[0013] Preferably, the dynamic parameter generator has a built-in multi-strategy environment simulation algorithm, which selects the appropriate strategy according to the needs of the scenario.

[0014] Preferably, the adaptation strategy includes a speed-first strategy and a precision-first strategy.

[0015] In summary, this invention provides a cloud phone environment initialization system based on Android debug bridge commands. From the generation of three types of request parameters, to the integration and optimization of parameter set aggregation and verification, and finally to the implementation and effectiveness of the ADB-based execution engine, the entire process forms a closed loop of "source parameter generation → multi-source integration → compliance verification → secure execution → instance output". This mechanism not only ensures the high simulation of parameters (close to real devices and environments), but also solves the conflict problem of multi-source parameters through aggregation and verification. Finally, with the atomic operation of the ADB execution engine, it achieves efficient, secure, and batch initialization of the cloud phone environment, providing core technical support for scenarios such as automated testing and marketing operations. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be discussed below. Obviously, the technical solutions described in conjunction with the accompanying drawings are only some embodiments of the present invention. For those skilled in the art, other embodiments and their accompanying drawings can be obtained based on the embodiments shown in these drawings without creative effort.

[0017] Figure 1 A general system block diagram of a cloud phone environment initialization system based on Android debug bridge commands according to the present invention is shown.

[0018] Figure 2 A flowchart illustrating the specific operation of the cloud phone environment initialization system based on Android debug bridge commands according to the present invention is shown. Detailed Implementation

[0019] The technical solutions of various embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments described in the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In summary, to solve the aforementioned technical problems, this invention provides a variety of flexible methods by encapsulating a custom instruction set of Android ADB debugging bridge capabilities, allowing users to quickly and in batches modify various system parameters of cloud phone instances, thereby simulating any real mobile phone environment.

[0021] Specifically, this invention provides a method for initializing a cloud phone environment based on Android debug bridge commands, including a command receiving step, a parameter generation step, a parameter writing step, an application restart step, and a result feedback step. These steps will be described in detail below.

[0022] In the instruction receiving step, the user's cloud phone environment initialization request is received through preset multiple entry points. These multiple entry points include the UI operation of the cloud phone management backend, the command-line tools inside the cloud phone, the API calls of business applications, and the uploaded real device clone configuration file.

[0023] like Figure 1 As shown, the instruction receiving steps can rely on four user entry points: "real device cloning configuration file, background UI operation, OG command line, and business API call" to build an instruction capture and parsing system that covers diverse operation scenarios and adapts to different business needs. This system can accurately receive various instructions from users to initialize the cloud phone environment, laying the foundation for subsequent processes.

[0024] Specifically, the real device cloning configuration file entry meets users' needs for "replicating the real device environment". By uploading a configuration file containing complete information such as real device hardware parameters (such as IMEI code, Bluetooth address), system configuration (Android version, build number), and network environment (carrier information, base station parameters), the fingerprint of the real device is "migrated" to the cloud phone instance.

[0025] The backend UI operation entry is geared towards non-technical users such as operations personnel and testers, providing a WYSIWYG visual operation interface to lower the technical threshold for initializing the cloud phone environment.

[0026] The Og command-line entry serves technology research and development and automated operation and maintenance scenarios, providing a flexible and scriptable command input method and supporting complex parameter combinations and batch task orchestration.

[0027] The business API call entry point is geared towards third-party business systems (such as automated testing platforms and e-commerce marketing robots), providing standardized interfaces to achieve seamless integration between cloud phone environment initialization and business processes, supporting high-concurrency and automated business scenarios.

[0028] In the subsequent parameter generation step, a parameter set of the target device is generated or obtained in a corresponding manner according to the type of the initialization request. The parameter set includes at least one of hardware parameters, software parameters, system parameters, and dynamic environment parameters.

[0029] The next step is the parameter writing step, which establishes a communication channel with the underlying Android of the cloud phone through the encapsulated Android Debug Bridge (ADB) interface, and writes the parameter set into the corresponding system configuration items of the cloud phone instance in batches and atomically.

[0030] Then, in the next application restart step, the cloud phone instance is triggered to restart, so that the written parameter set takes effect.

[0031] Finally, the result feedback step returns the execution result to the initiator of the initialization request, informing whether the operation was successful.

[0032] The above description of each step has roughly clarified the basic framework of the method provided by this invention. The following will combine... Figure 2 The specific evolution of the present invention will be described below.

[0033] Figure 2 A flowchart illustrating the specific operation of the cloud phone environment initialization system based on Android debug bridge commands according to the present invention is shown.

[0034] like Figure 2 As shown, the system's input layer, as mentioned above, has four main entry points: dynamic information of cloud phones (such as IP addresses), a built-in device parameter library (which contains static data of multiple real devices; in practical applications, the term "multiple" often refers to a massive amount of data), an external clone configuration file, and user requests introduced by business API call entry points.

[0035] The dynamic information includes real-time or variable environmental data such as the cloud phone's current IP address, the user-specified geographical location (latitude and longitude / country / region), and network type (4G / 5G / WiFi). Its core is to "simulate the dynamic device status in real-world scenarios".

[0036] The built-in device parameter library stores static parameters (such as brand, model, motherboard information, system version, hardware configuration, etc.) of multiple (often in massive quantities) real devices. Its core is "reusing the standardized fingerprints of real devices".

[0037] An external clone configuration file is a snapshot of the complete parameters of a specific real device uploaded by the user (including IMEI, Bluetooth address, system settings, and even application data). Its core is to "replicate all the characteristics of a real device".

[0038] like Figure 2 As shown, user requests initiated by the business API call entry point are input into the unified instruction parsing module in the system core processor. The system core processor includes the unified instruction parsing module, the parameter set aggregation and verification module, the parameter source intelligent selection and verification module, and the execution engine.

[0039] In summary, after the user request is parsed by the unified instruction parsing module, it is introduced into the parameter source intelligent selection and verification module. Through intelligent selection and verification, the request type is formed.

[0040] The user requests received by the business API call entry point usually come from third-party business systems (such as automated testing platforms, e-commerce marketing engines, etc.), and their form is a structured request that conforms to the OpenAPI specification (such as an HTTP POST request with a JSON request body).

[0041] After the user request undergoes authentication (Token verification), traffic control, and basic format verification via the API gateway, it is forwarded to the system's core processor, where it first enters the unified instruction parsing module. At this point, the original parameters of the API request (such as model_type and region) still maintain the business system's custom format and need to be parsed and converted into standardized instructions that the system can recognize.

[0042] The internal instructions, processed by the unified instruction parsing module, are then passed to the parameter source intelligent selection and verification module. The core function of this module is to determine the parameter source based on the operation_type and its auxiliary parameters in the instruction, verify the availability and matching of the parameter source, and ultimately generate a clear request type.

[0043] In the parameter source intelligent selection and verification module, if the parameter source comes from dynamic information, the parameter source intelligent selection and verification module outputs the environment simulation request type.

[0044] For example, if a user specifies "geographic location = Berlin, Germany" through the business API, the system will use this dynamic information as the core parameter source to generate an "environment simulation request type". Subsequently, the system will call the dynamic parameter generator to match the base station information in Germany, the German language environment, and the network parameters of the EU frequency band.

[0045] In the parameter source intelligent selection and verification module, if the parameter source comes from the built-in device parameter library, the parameter source intelligent selection and verification module outputs the device selection request type.

[0046] The device selection request type explicitly requires the system to filter or extract parameters from the built-in device parameter library, focusing on the "device authenticity" of the parameters (such as brand and model matching, hardware and system version compatibility). Depending on the filtering logic, it can be further subdivided into: Subtype 1: Request for a specified model (e.g., "extract parameters for Xiaomi 13 from the library"); Subtype 2: Request for a specified brand (e.g., "randomly select from the parameter set of Huawei brand devices in the library"); Subtype 3: Request for a random model (e.g., "randomly extract parameters from all models in the library").

[0047] For example, when a user selects the "iPhone 14" model through the background UI, the system uses the parameters of iPhone 14 in the built-in device parameter library as the parameter source to generate a "Device Selection Request Type (Specified Model Subtype)" to ensure that the output parameters are consistent with the hardware and system characteristics of the real iPhone 14.

[0048] In the parameter source intelligent selection and verification module, if the parameter source comes from an external clone configuration file, the parameter source intelligent selection and verification module outputs a clone replication request type.

[0049] The cloning and replication request type explicitly requires the system to parse and reuse the parameters in the configuration file, with an emphasis on the "integrity" and "consistency" of the parameters (strictly adhering to the parameter associations of the original device, and not allowing unauthorized modifications).

[0050] For example, a user uploads a clone configuration file of an OPPO Find X6 via the og command line. The system uses this as a parameter source to generate a "clone replication request type", and will then completely replicate the phone's hardware fingerprint, system configuration, and environmental parameters according to the file content.

[0051] The following section will continue to describe the operation of the decision-making and generation modules in the system.

[0052] In the decision-making and generation module, when the environment simulation request type is output, the system automatically calls the dynamic parameter generator to receive the environment simulation request type, and then inputs dynamic information (such as the user-specified geographical location "London, UK", the current IP of the cloud phone "51.06.73.65", and the network type "5G") into the generator. The generator has a built-in multi-strategy environment simulation algorithm, and an adaptation strategy can be selected according to the scenario requirements.

[0053] For example, the speed-first strategy: if the business needs to generate parameters quickly (such as batch initialization of marketing campaigns), the algorithm first determines the mainstream operators (such as EE, Vodafone) based on "UK", and randomly matches base station information (LAC=1234, CI=5678) from the preset base station data subset of the operator, combined with parameters such as IP location to supplement time zone (GMT+0) and language (en-GB).

[0054] For example, the precision-first strategy: If the business requires high-precision simulation (such as risk control testing), the algorithm searches for the three nearest real base stations in the global base station database based on London's latitude and longitude (51.5074° N, 0.1278° W), calculates the signal strength weight, selects the optimal base station (such as EE's Tower ID=9876), reverse-engineers the operator information, and generates dynamic parameters consistent with the real environment (including details such as base station signal strength and roaming status).

[0055] Once the dynamic parameter generator is triggered, its core output is a set of dynamic simulation parameters adapted to the target scenario, which is directly passed to the parameter set aggregation and verification module. This parameter set is a structured data set that is strongly correlated with the real-time environment and can simulate the dynamic characteristics of real devices. It aims to make the operating environment of cloud phones closer to the scenario-based state of real physical devices, thereby improving the realism and credibility of the environment simulation.

[0056] When a "Device Selection Request Type" (such as "Specify Model = Google Pixel 7" or "Random Brand = Samsung") is generated and input into the decision and generation module, the parameter source intelligent selection module within that module will locate it to the built-in device parameter library. This library stores numerous static parameters, typically in massive quantities, such as over 100,000 static parameters from real devices. These parameters can be categorized hierarchically by "Brand - Series - Model," and each record contains complete hardware and system characteristics.

[0057] Hardware parameters: Brand (Google), Model (Pixel 7), Motherboard model (Panther), CPU model (GoogleTensor G2), Memory (8GB), Storage (128GB), Screen resolution (2400×1080), etc.; System parameters: Android version, build number (e.g., TP1A.221005.002), Baseband version, etc.

[0058] Next, let's introduce the logic for extracting static parameters. If it is a "specified model request": the corresponding complete parameter set is directly extracted by precise model matching (such as "Pixel 7"). If it is a "random model request": a record is randomly selected from the filter library based on additional conditions (such as "supports 5G" and "Android 13+") and the parameters are extracted. If it is a "specified brand request": a model is randomly selected from the brand subset (such as Galaxy S23 from the Samsung subset) and its parameters are extracted.

[0059] The extracted static parameters are marked as "static source parameters" and directly passed to the parameter set aggregation and verification module.

[0060] When a "clone replication request type" is generated and input into the decision and generation module, the external configuration parsing subunit reads the external cloning configuration file uploaded by the user (such as real_iphone13.json). This file is a complete parameter snapshot of the target device, including: immutable hardware identifiers: IMEI (356789012345678), MEID (A1000012345678), Bluetooth MAC (00:1A:7D:DA:71:13), WiFi MAC (AC:BC:32:85:8A:7D), etc.; system configuration: iOS version (16.5), device name ("John's iPhone"), region setting (United States), privacy settings (such as "location services enabled"), etc.; application data snapshot: list of installed applications (WeChat, TikTok, etc.), application permission settings (such as WeChat has obtained location permissions), etc.

[0061] During the parsing process, the system will verify the integrity of the file (such as whether it contains required fields such as IMEI and model number) and the legality of the format (such as the IMEI must be a 15-digit number), and remove malicious parameters (such as a forged baseband version).

[0062] The parsed parameters are converted into a system-wide format (aligned with static and dynamic parameter fields), marked as "external source parameters," and passed to the parameter set aggregation and validation module.

[0063] The parameter set aggregation and verification module is the "data integration hub" of the system's core processing layer. It is responsible for merging the incoming dynamic simulation parameter set, static source parameters, and external source parameters into a composite parameter set, and ensuring its compliance and availability through multi-dimensional verification.

[0064] For example, aggregation logic can merge parameters according to the priority of the parameter source and the field correlation, following a three-source parameter aggregation rule. In the three-source parameter aggregation rule, static source parameters form the basic framework, external source parameters cover specific fields that need to be replicated (such as the application list), and dynamic simulation parameter sets supplement environmental information, forming a composite parameter set that "takes into account both the basic framework and customized fields, as well as environmental adaptation."

[0065] The parameter set aggregation and verification module, as its name suggests, performs two functions: aggregation and verification. The composite parameter set formed by aggregation is verified in the parameter set aggregation and verification module to form a compliant parameter set.

[0066] For example, the parameter set aggregation and verification module ensures the formation of a usable verification parameter set through three layers of verification logic. First, logical consistency verification: hardware correlation: brand and model must match (e.g., the "Iphone" brand cannot correspond to the "Galaxy S23" model); second, system compatibility verification: the system version must match the hardware (e.g., Android 13 cannot run on parameters of older models that only support Android 10); third, environmental adaptability verification: dynamic network parameters must be compatible with the frequency bands supported by the static device (e.g., the Pixel 7 supports European 5G frequency bands, so the "EE Carrier 5G" parameter is valid).

[0067] Subsequent verification may also include format validity checks: for identifier parameters, the IMEI must be a 15-digit number, and the MAC address must conform to the format "XX:XX:XX:XX:XX:XX"; for enumeration parameters, the network type can only be a predefined value such as "4G", "5G", or "WiFi", and the time zone must conform to the IANA standard (such as "Asia / Shanghai").

[0068] Then, risk avoidance verification can be performed: Deduplication: During batch initialization, ensure that the key identifiers (IMEI, MEID) of different cloud phone instances are not repeated to avoid being identified as a "device cluster" by risk control; Authenticity: The hardware and system characteristics in the parameter set must be consistent with the distribution pattern of real devices (e.g., low-end models will not be configured with 12GB of memory).

[0069] If the verification fails, the module will trigger a correction mechanism: minor conflicts (such as time zone and language mismatch) will be automatically corrected (the language "en-US" will be changed to "en-GB" to match the London time zone); serious conflicts (such as brand and model mismatch) will return an error message, requiring the user to adjust the parameter source.

[0070] The aggregated and verified set of compliant parameters is ultimately input into the execution engine based on ADB (Android Debug Bridge), which is the "execution terminal" for the parameters to be executed on the cloud phone instance.

[0071] Here's an example of the execution engine's operation process. First, there's the ADB command encapsulation and batch processing: the execution engine maps the fields in the parameter set to underlying Android system attribute modification commands, and sends them to the cloud phone through the encapsulated ADB interface.

[0072] Then, regarding hardware parameters, modify system properties using the setprop command (e.g., setpropro.product.brand Google to set the brand); regarding network parameters, configure the network using the svc command (e.g., svcdata enable to enable data network) + setprop to modify base station information; regarding the system environment, set the time zone using setproppersist.sys.timezone Europe / London.

[0073] The execution engine adopts a "transactional batch processing" mode: all ADB commands corresponding to parameters are packaged into a task package and executed in the order of dependencies (such as modifying hardware parameters first and then configuring the network) to ensure that the parameters take effect in the correct order.

[0074] After the parameters are successfully written, the execution engine automatically triggers a restart of the cloud phone (via the adb reboot command), so that the new parameters are loaded and take effect when the system starts. After the restart is complete, the engine uses the adb getprop command to verify the actual values ​​of key parameters (such as brand, model, and time zone). Once it confirms that the values ​​are consistent with the target parameter set, it generates a "Parameter modification complete" report.

[0075] Ultimately, the cloud phone instance with modified parameters is delivered to the user (or business system) and can be directly used for target scenarios (such as Pixel 7 devices simulating the London environment for overseas application testing).

[0076] Therefore, the cloud phone environment initialization system based on Android debug bridge commands according to the present invention forms a closed loop from the generation of three types of request parameters, to the integration and optimization of parameter set aggregation and verification, and then to the implementation and effectiveness of the ADB-based execution engine: "source parameter generation → multi-source integration → compliance verification → secure execution → instance output". This mechanism not only ensures the high simulation of parameters (close to real devices and environments), but also solves the conflict problem of multi-source parameters through aggregation and verification. Finally, with the help of the atomic operation of the ADB execution engine, it realizes efficient, secure, and batch initialization of the cloud phone environment, providing core technical support for scenarios such as automated testing and marketing operations.

[0077] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. The scope of protection of the present invention is determined by the appended claims. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A cloud phone environment initialization system based on Android debug bridge commands, characterized in that, include: The input layer contains dynamic information about the cloud phone, a built-in device parameter library, an external clone configuration file, and user requests introduced by the business API call entry point. The system's core processor includes an instruction unified parsing module, a parameter set aggregation and verification module, a parameter source intelligent selection and verification module, and an execution engine. User requests are parsed by the instruction unified parsing module to form internal instructions, which are then passed to the parameter source intelligent selection and verification module. Cloud phone dynamic information serves as a parameter source to match the internal instructions and outputs an environment simulation request type from the parameter source intelligent selection and verification module. The built-in device parameter library serves as a parameter source and outputs a device selection request type from the parameter source intelligent selection and verification module. The external clone configuration file serves as a parameter source and outputs a clone replication request type from the parameter source intelligent selection and verification module. The decision-making and generation module takes the environment simulation request type as input, and the dynamic parameter generator is invoked and input with the cloud phone's dynamic information to adapt to the environment simulation request type, forming a dynamic simulation parameter set; the device selection request type is input to the decision-making and generation module and located to the built-in device parameter library, from which static source parameters are extracted; the cloning and replication request type is input to the decision-making and generation module, and based on this type, the external cloning configuration file is parsed to extract external source parameters; The parameter set aggregation and verification module merges the dynamic simulation parameter set, static source parameters, and external source parameters into a composite parameter set. After verification in the parameter set aggregation and verification module, the composite parameter set forms a compliant parameter set. The compliant parameter set is then written to the cloud phone instance after ADB debugging in the execution engine.

2. The system according to claim 1, characterized in that, The dynamic information of the cloud phone includes the current IP address of the cloud phone, the geographical location specified by the user, and the network type.

3. The system according to claim 1, characterized in that, The built-in device parameter library stores static parameters of multiple real devices.

4. The system according to claim 1, characterized in that, External clone configuration files are snapshots of the complete parameters of a real device uploaded by the user.

5. The system according to claim 1, characterized in that, User requests originate from third-party business systems and are structured requests conforming to the OpenAPI specification.

6. The system according to claim 1, characterized in that, The device selection request type includes three subtypes: specified model request, specified brand request, and random model request.

7. The system according to claim 1, characterized in that, The dynamic parameter generator has a built-in multi-strategy environment simulation algorithm that selects the appropriate strategy based on the scenario requirements.

8. The system according to claim 7, characterized in that, The adaptation strategies include a speed-first strategy and a precision-first strategy.

Images