Multi-scene function adaptation method and system, electronic equipment and readable storage medium

Abstract

The invention discloses a multi-scene function adaptation method and system, electronic equipment and a readable storage medium, and relates to the field of product tests.The method comprises the steps that firmware of a first function module and firmware of a second function module are burnt to equipment to be tested, the first function module is used for achieving a preset function in a specific scene, and the second function module is used for achieving a preset function in a specific scene; the second function module and the first function module have the same function but adopt different implementation modes; setting a flag bit with a setting state and a zero clearing state in the secure storage; and starting the first function module or the second function module according to the flag bit. According to the method, the first function module and the second function module which have the same function but different implementation modes are preset, and which module is started is controlled through the flag bit, so that flexible switching of system functions is realized, and the same firmware can adapt to the requirements of different scenes. Taking ADB connection as an example, the problem of conflict of Android products to ADB connection requirements in a test stage and a user use stage can be solved by presetting ADB modules following different connection strategies.

Description

Technical Field

[0001] The present application relates to the field of product testing, and in particular to a multi-scenario function adaptation method, system, electronic device and readable storage medium. Background Art

[0002] With the widespread adoption of smart mobile devices, Android has become one of the leading operating systems in the market due to its openness and high degree of customization. During the R&D, production, and testing of Android devices, the use of specific functional modules is crucial for improving work efficiency.

[0003] In the automated testing system for Android products, communication between the host PC and the Android device relies on specific functional modules to complete the transmission of test instructions, the execution of test operations, and the feedback of test results. Under certain system firmware environments, some key functions of these functional modules are restricted, resulting in the inability to automatically establish a connection between devices.

[0004] In particular, the ADB (Android Debug Bridge) module is extremely important in manual debugging and automated testing. It can establish communication between the PC and the Android device via USB or other media. Under the conventional Android testing system, if the device is in the "userdebug" version, it can be automatically connected directly through ADB; but for the more stringent "user" version (often the official version for final release or certification), the system will impose permission and security restrictions on key functions such as ADB, resulting in ADB being unable to automatically connect during production line testing or development testing, and manual operation is required to enable the connection. This not only increases the complexity of the testing process, but may also require repeated burning of different versions of firmware, reducing testing efficiency. In addition, some existing solutions attempt to achieve automatic testing by modifying the ADB function in the "user" version of the firmware and enabling the ADB connection by default, but this often introduces new security risks and is not suitable for actual mass production use. It also does not meet the system security requirements for occasions such as Google GMS certification. At the same time, there are also ways in the industry to enable ADB by simulating mouse or keyboard input, and coordinating visual analysis with robotic arms to operate the UI. However, such solutions require additional hardware or complex configuration of the UI, have limited flexibility and stability, and are also costly.

[0005] It can be seen from this that how to ensure the system's security policy in the "user" version of Android firmware officially released, and automatically enable key functional modules (such as ADB) in specific scenarios to support automated testing, has become a technical problem that needs to be solved urgently in the industry. Summary of the Invention

[0006] This application aims to solve at least one of the technical problems existing in the prior art. To this end, this application proposes a multi-scenario function adaptation method, system, electronic device, and readable storage medium that can meet the differentiated functional requirements in various scenarios while ensuring the overall security and ease of use of the system.

[0007] In a first aspect, an embodiment of the present application provides a multi-scenario function adaptation method. The multi-scenario function adaptation method according to an embodiment of the present application includes:

[0008] Burning the firmware of the first functional module and the second functional module into the device under test, wherein the first functional module is used to implement a predetermined function in a specific scenario, and the second functional module has the same function as the first functional module but adopts a different implementation method;

[0009] Setting a flag in a secure storage of the device, the flag having a set state and a cleared state;

[0010] The first functional module or the second functional module is enabled according to the flag bit.

[0011] According to the multi-scenario function adaptation method of the embodiment of the present application, there are at least the following beneficial effects: the present application burns a first function module and a second function module with the same function but different implementation methods in the device to be tested, and sets a flag bit in the device's secure storage area, so that the system can flexibly enable the function module that meets specific needs according to the state of the flag bit. Since two sets of function implementations are pre-deployed on the device, when customized activation is required for a certain scenario, the target function module can be switched only by adjusting the flag bit, avoiding repeated modification or replacement of the system image and improving the flexibility of function expansion. By setting a settable or clearable flag bit in the device's secure storage, different usage scenarios (such as test scenarios and user usage scenarios) can be effectively distinguished, so that specific functional requirements can be met in testing or special scenarios, and the security of the system can be guaranteed during the user use phase, taking into account the balance between functionality and security. The present application is not limited to a single functional module in design, and can also adopt the same idea for differentiated deployment for multiple modules (such as network protocol stack, DNS resolution, remote key management, etc.) in the Android system to meet the customized requirements for network, DNS, key management, etc. in specific scenarios, and has wide applicability.

[0012] In an automated test scenario, if the two sets of functional modules are applied to the ADB module respectively, the ADB connection function that meets the test requirements can be enabled by default on the device after the firmware is burned, so as to achieve real-time control and debugging of the device under test and significantly improve the test efficiency. After the test is completed, the default ADB connection can be closed by restoring the flag bit to the initial state, returning to the normal user usage mode, thereby taking into account both test convenience and user safety. Compared with the method of deeply modifying the system image or relying on additional hardware devices, the present invention can effectively avoid security vulnerabilities in the User version environment and reduce the cost of repeated burning and version switching. In summary, the solution proposed in this application of deploying functional modules with the same functions but different implementation methods in the device under test and switching them through the secure storage area flag bit can not only meet the differentiated functional requirements in various scenarios, but also ensure the overall security and ease of use of the system, and has significant promotion value and application prospects.

[0013] According to some embodiments of the present application, the first function module and the second function module are ADB modules, wherein the first function module enables ADB connection only when the user chooses to turn it on, and the second function module enables ADB connection by default.

[0014] According to some embodiments of the present application, setting a flag bit in the secure storage of the device includes:

[0015] In response to a first instruction, modifying the flag bit in the secure storage to the set state; wherein the first instruction is used to indicate that the device is in a test state;

[0016] In response to a second instruction, modifying the flag bit in the secure storage to the cleared state; wherein the second instruction is used to indicate that the device is in a user-used state;

[0017] According to some embodiments of the present application, enabling the first functional module or the second functional module according to the flag bit includes:

[0018] Controlling the boot program to read the flag bit in the secure storage;

[0019] Controlling the boot program to convert the flag bit into boot configuration information in the memory;

[0020] Controlling a preset system initialization process to convert the boot configuration information into attribute information for storage;

[0021] The corresponding first function module or second function module is loaded according to the stored attribute information to provide an ADB connection service for the device.

[0022] According to some embodiments of the present application, burning the firmware of the first functional module and the second functional module to the device under test includes:

[0023] Burning the firmware of the first functional module to the system partition of the device;

[0024] Burn the firmware of the second functional module to the vendor partition of the device.

[0025] According to some embodiments of the present application, the further comprising:

[0026] In response to the setting state of the flag bit, a prompt is provided through a system interface indicating that the current device is in a test mode.

[0027] According to some embodiments of the present application, the further comprising:

[0028] When the device completes the test, the device is restored to factory settings, so that the flag bit is in the cleared state, so that the device turns off the ADB automatic connection function.

[0029] In a second aspect, the present application provides a multi-scenario function adaptation system, including:

[0030] A first functional module, wherein the first functional module is used to implement a predetermined function in a specific scenario;

[0031] a second functional module, which has the same function as the first functional module but is implemented in a different manner;

[0032] A security storage module, used for storing a flag bit, wherein the flag bit has a set state and a cleared state;

[0033] An authority control module is used to read the flag bit and convert the flag bit into boot configuration information in the memory;

[0034] The initialization module is used to convert the boot configuration information into attribute information for storage, and load the corresponding first function module or second function module according to the attribute information.

[0035] In a third aspect, the present application provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein when the processor executes the computer program, the multi-scenario function adaptation method described in any one of the embodiments of the first aspect is implemented.

[0036] In a fourth aspect, the present application provides a readable storage medium, comprising computer-executable instructions stored therein, wherein the computer-executable instructions are used to execute the multi-scenario function adaptation method of any embodiment of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The present application is further described below with reference to the accompanying drawings and embodiments, wherein:

[0038] Figure 1 This is the main flow chart of the multi-scenario function adaptation method according to the embodiment of the present application;

[0039] Figure 2 for Figure 1 Flowchart of step S300 in the ADB connection application scenario;

[0040] Figure 3 Schematic diagram of the structure of an electronic device according to an embodiment.

[0041] Reference numerals:

[0042] Processor 101 ; memory 102 ; input / output interface 103 ; communication interface 104 ; bus 105 . DETAILED DESCRIPTION

[0043] The following describes in detail embodiments of the present application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application and are not to be construed as limiting the present application.

[0044] In the description of this application, it should be understood that descriptions involving orientations, such as up, down, front, back, left, right, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, they cannot be understood as limitations on this application.

[0045] In the description of this application, "several" means more than one, "plurality" means more than two, "greater than," "less than," and "exceed" are understood to exclude the number itself, while "above," "below," and "within" are understood to include the number itself. The use of "first" and "second" in the description is solely for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance, implicitly specifying the number of the indicated technical features, or implicitly specifying the order of the indicated technical features.

[0046] In the description of this application, unless otherwise clearly defined, terms such as setting, installing, and connecting should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meanings of the above terms in this application based on the specific content of the technical solution.

[0047] In the description of this application, reference to the terms "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples.

[0048] like Figure 1 As shown, the multi-scenario function adaptation method of the embodiment includes:

[0049] S100: Burn the firmware of a first functional module and a second functional module to a device under test, wherein the first functional module is used to implement a predetermined function in a specific scenario, and the second functional module has the same function as the first functional module but is implemented in a different manner.

[0050] S200: Setting a flag in a secure storage of a device, wherein the flag has a set state and a cleared state.

[0051] S300: Enable the first functional module or the second functional module according to the flag bit.

[0052] In step S100, both the first and second functional modules implement the same functions, such as a network protocol stack and DNS resolution, but differ in their specific implementations, such as implementation paths, compilation configurations, or service initialization processes. To accommodate differentiated functional requirements in different scenarios, in some embodiments, the first and second functional modules can be placed in different partitions, for example, deploying the first functional module in the system partition and the second functional module in the vendor partition. Alternatively, appropriate partitions can be selected for deployment based on actual needs.

[0053] After compiling and packaging the designated first and second functional modules, use production tools or a flashing method such as Fastboot to flash the corresponding partition firmware to the device under test. After flashing, the device under test now contains two sets of modules with the same functionality but different implementations, laying the foundation for selecting the appropriate functional module based on different scenarios.

[0054] In step S200 and step S300, a flag bit is set in the device's secure storage area (such as a secure storage space accessible to the Bootloader) to indicate whether a function is on / off or in different operating modes. The flag bit has two forms: a "set state" and a "clear state". For example, when the flag bit is in the set state, it indicates that the current device needs to enable the second functional module in order to meet the functional requirements of a specific scenario (such as an automated test mode). When the flag bit is in the cleared state, it indicates that the current device should return to the normal user usage scenario and only needs to enable the first functional module.

[0055] During mass production testing or specific upgrade operations, control instructions can be executed to write (set or clear) flags in secure storage. To avoid affecting normal user use, the system or burning software can use permission verification or validation mechanisms to ensure that only specific trusted operations (such as factory testing or restoring factory settings) can change flags, preventing ordinary users from unknowingly enabling functions that pose security risks.

[0056] The embodiment of the multi-scenario function adaptation method is to deploy two sets of modules with different implementation methods but the same functions in different partitions, and set a set / clear flag in the secure storage to flexibly switch the function modules that should be enabled in different usage scenarios of the device under test. Since two sets of function implementations are pre-deployed on the device, when customized activation is required for a certain scenario, the target function module can be switched only by adjusting the flag, avoiding repeated modification or replacement of the system image, and improving the flexibility of function expansion. By setting a set or clear flag in the device secure storage, different usage scenarios (such as test scenarios and user usage scenarios) can be effectively distinguished, so that specific functional requirements can be met in testing or special scenarios, and the security of the system can be guaranteed in the user use stage, taking into account the balance between functionality and security. The present application is not limited to a single functional module in design, and can adopt the same idea for differentiated deployment for multiple modules (such as network protocol stack, DNS resolution, remote key management, etc.) in the Android system to meet the customization requirements for network, DNS, key management, etc. in specific scenarios, and has wide applicability.

[0057] Testing is crucial throughout the development, production, and use cycles of smart devices. Specifically, in the automated testing of Android products, communication between the PC host and the Android device relies on specific functional modules to transmit test instructions, execute test operations, and provide result feedback. The ADB module is the core bridge for communication between Android devices and PCs. Therefore, the following uses the ADB functional module as an example to explain in detail the implementation of the multi-scenario functional adaptation method in this application.

[0058] In step S100, both the first function module and the second function module are ADB modules, wherein the first function module enables the ADB connection only when the user chooses to turn it on, and the second function module enables the ADB connection by default. For example, the first function module can be deployed in the system partition (System Partition), and the first function module presets the conventional ADB function. This module follows the security policy of the official Android User version and will not directly establish an ADB connection with the PC after the device is started by default; the second function module is deployed in the vendor partition (Vendor Partition), and the first function module is a specially compiled or configured ADB module, so that it enables the ADB connection by default after the device is started. Therefore, the second function module can immediately establish ADB communication with the PC in specific scenarios (such as production line testing, Google GMS testing, etc.) without manual operation by the user, which facilitates the automated test script to quickly debug, configure and test the device.

[0059] Both the system partition and the vendor partition contain modules with ADB functionality, but their implementation strategies or compilation options differ: the first module requires user intervention to take effect, while the second is enabled by default. Because the Android system recognizes different modules in partitions when loading services, there's no need to worry about loading conflicts. The system uses flags and processing procedures, described later, to selectively enable the first or second module.

[0060] In step S200, setting a flag in the secure storage of the device includes but is not limited to:

[0061] In response to the first instruction, the flag bit in the secure storage is modified to a set state, wherein the first instruction is used to indicate that the device is in a test state. During product factory testing or specific upgrade scenarios, the production line tool issues a first instruction to the Bootloader or the corresponding management program through the USB or serial port, instructing the device to enter the "test state". After receiving the first instruction, the device accesses the secure storage area and modifies the flag bit to a set state (for example, writes "1"). After the setting is successful, when the system is restarted or powered on again, the Bootloader will read this state and load the second function module that enables ADB by default to meet the needs of automated testing. After the device detects that the flag bit has been set, it will switch to the second function module at startup, allowing the test platform to connect to the device and execute the script without manual intervention.

[0062] In response to the second instruction, the flag bit in the secure storage is modified to a cleared state, wherein the second instruction is used to indicate that the device is in user use. When the test task is completed, the system's factory reset operation can be triggered; when this action is performed, the system will send a second instruction to the Bootloader or related management module to clear the flag bit. After the flag bit is cleared, when the device restarts, the first functional module will be loaded in the System partition. This module follows the User version policy and closes the ADB connection by default or requires user authorization to open it, thereby returning to normal security mode. When the device is officially delivered to the user, this mode can effectively prevent the device from potential security risks.

[0063] Understandable, such as Figure 2 As shown, step S300 includes but is not limited to steps S310 to S340:

[0064] S310, controlling the boot program to read the flag bit in the secure storage;

[0065] S320, controlling the boot program to convert the flag bit into boot configuration information in the memory;

[0066] S330, the controlled system initialization process converts the boot configuration information into attribute information for storage;

[0067] S340: Load the corresponding first function module or second function module according to the stored attribute information to provide an ADB connection service for the device.

[0068] In step S310, the bootloader reads the secure storage area through the underlying read / write interface (which can be based on the API provided by the SoC manufacturer or the bootloader's own logic) and records the current state of the flag (set / cleared) and stores it in a public structure or environment variable defined by the bootloader. For example, if the flag value is 1 (Y), it indicates the test state; if the flag value is 0 (N), it indicates the user state. This value will be further parsed and transmitted in subsequent stages.

[0069] In step S320, after reading the flag, the bootloader maps the flag value to BootConfig. BootConfig can be a structure that records various boot parameters and is stored at a fixed memory address or in a specific storage range. Optionally, for security reasons, the bootloader can verify the flag before writing to BootConfig to prevent accidental or unauthorized modifications.

[0070] In step S330, the initialization process obtains the flag value through a specific reading mechanism (for example, reading the BootConfig mapping address in memory). The initialization process converts this flag value into property information (such as ro.boot.adb_switch) and persists it in the property system. As a result, the system's subsequent service startup script can determine the specific ADB service activation policy by reading this property value.

[0071] In step S340, the initialization process will first scan the rc files in the entire device, give a service list, and check the above-mentioned attribute information. If the attribute represents the "test status", the second function module located in the Vendor partition will be started first (ADB connection is automatically enabled by default); if the attribute represents the "user use status", only the first function module located in the System partition will be loaded, and it will only take effect when the user manually turns it on. In order to avoid conflicts, the ADB function files in the system partition and the vendor partition are generally not activated at the same time: when the test flag is set, the ADB main service in the Vendor partition binds the port and receives connections; when the flag is cleared, the ADB service of the Vendor partition will not be listed as available, and the system still uses the ADB function policy of the System partition.

[0072] Optionally, to prevent mass-produced devices from entering the market, devices in test mode (with a flag set) will display a clear notification on the system UI (e.g., a pop-up window reminding users that the device is currently in production line test mode) to prevent the accidental delivery of products in this state. Once users or after-sales personnel notice this notification, they can use the factory reset command to clear the flag and disable the default ADB, completing the transition from "test mode" to "user mode."

[0073] In a second aspect, the present application provides a multi-scenario function adaptation system, including: a first function module, a second function module, a security storage module, a permission control module and an initialization module.

[0074] Optionally, the first functional module is deployed in the system partition (such as System Partition), which complies with the official Android security policy for the User version. By default, the ADB connection is not actively opened to the outside world. ADB will only be enabled after the user authorizes it through "Developer Options" or other methods. It is suitable for daily use by end users to ensure the security and compliance of the system; the second functional module is deployed in the vendor partition (such as Vendor Partition), which is specially designed or compiled to enable ADB connection by default. It is mainly used in scenarios such as production line testing and GMS certification testing that require fast and large-scale automated testing. After the device is started, it immediately provides ADB access to the PC through the USB port without manual operation, which can greatly improve test efficiency.

[0075] It is understandable that the secure storage module is used to store the flag bit for ADB automatic connection (for example, 0 represents off and 1 represents on). It is usually managed by the Bootloader or other trusted firmware, and the flag bit is only allowed to be modified during specific trusted operations (such as mass production tool instructions or restoring factory settings) to prevent abuse by ordinary users or unsafe programs. The permission control module is integrated into the Bootloader or early startup link, and is responsible for reading the flag bit in the secure storage module and converting the flag bit into the boot configuration information (BootConfig) in the memory. During the startup of the Android operating system, the initialization module controls the initialization process to read the boot configuration information, converts it into system properties (such as ro.boot.adb_switch), and stores it persistently. Subsequently, through the system property mechanism, the initialization process decides whether to load the first functional module or the second functional module, thereby realizing the switching of "default off" or "default on" ADB.

[0076] In a third aspect, embodiments of the present application further provide an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the multi-scenario function adaptation method when executing the computer program. The electronic device can be any smart terminal, including a tablet computer and an in-vehicle computer.

[0077] See Figure 3 , Figure 3 The hardware structure of an electronic device according to another embodiment is shown. The electronic device includes:

[0078] The processor 101 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0079] The memory 102 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 102 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 102, and the processor 101 calls and executes the multi-scenario function adaptation method of the embodiments of this application;

[0080] Input / output interface 103, used to implement information input and output;

[0081] Communication interface 104, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0082] bus 105 , which transmits information between the various components of the device (e.g., processor 101 , memory 102 , input / output interface 103 , and communication interface 104 );

[0083] The processor 101 , the memory 102 , the input / output interface 103 and the communication interface 104 are connected to each other in communication within the device via a bus 105 .

[0084] Since the electronic device of the third aspect can implement the multi-scenario function adaptation method of any embodiment of the first aspect when executing the computer program, it has all the beneficial effects of the first aspect of this application.

[0085] In a fourth aspect, the present application also provides a computer storage medium, including computer executable instructions stored therein, which are used to execute the multi-scenario function adaptation method of any embodiment of the first aspect.

[0086] Since the computer storage medium of the fourth aspect can execute the multi-scenario function adaptation method of any embodiment of the first aspect, it has all the beneficial effects of the first aspect of this application.

[0087] It should be understood that the term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information (such as computer-readable instructions, data structures, program modules or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0088] The embodiments of the present application have been described in detail above with reference to the accompanying drawings. However, the present application is not limited to the above embodiments. Various modifications can be made within the scope of knowledge possessed by ordinary technicians in the relevant technical field without departing from the purpose of the present application. In addition, the embodiments of the present application and the features of the embodiments can be combined with each other unless there is a conflict.

Claims

1. A multi-scenario function adaptation method, characterized in that: include: Burning the firmware of the first functional module and the second functional module into the device under test, wherein the first functional module is used to implement a predetermined function in a specific scenario, and the second functional module has the same function as the first functional module but adopts a different implementation method; Setting a flag in a secure storage of the device, the flag having a set state and a cleared state; The first functional module or the second functional module is enabled according to the flag bit.

2. The multi-scenario function adaptation method according to claim 1, characterized in that: The first function module and the second function module are ADB modules, wherein the first function module enables ADB connection only when the user chooses to turn it on, and the second function module enables ADB connection by default.

3. The multi-scenario function adaptation method according to claim 2, characterized in that: Setting a flag bit in the secure storage of the device includes: In response to a first instruction, modifying the flag bit in the secure storage to the set state; wherein the first instruction is used to indicate that the device is in a test state; In response to a second instruction, the flag bit in the secure storage is modified to the cleared state; wherein the second instruction is used to indicate that the device is in a user-used state.

4. The multi-scenario function adaptation method according to claim 2, characterized in that: The enabling of the first functional module or the second functional module according to the flag bit includes: Controlling the boot program to read the flag bit in the secure storage; Controlling the boot program to convert the flag bit into boot configuration information in the memory; Controlling a preset system initialization process to convert the boot configuration information into attribute information for storage; The corresponding first function module or second function module is loaded according to the stored attribute information to provide an ADB connection service for the device.

5. The multi-scenario function adaptation method according to claim 2, characterized in that: Burning the firmware of the first functional module and the second functional module to the device under test includes: Burning the firmware of the first functional module to the system partition of the device; Burn the firmware of the second functional module to the vendor partition of the device.

6. The multi-scenario function adaptation method according to claim 3, characterized in that: Also includes: In response to the setting state of the flag bit, a prompt is provided through a system interface indicating that the current device is in a test mode.

7. The multi-scenario function adaptation method according to claim 6, characterized in that: Also includes: When the device completes the test, the device is restored to factory settings, so that the flag bit is in the cleared state, so that the device turns off the ADB automatic connection function.

8. A multi-scenario function adaptation system, characterized in that: include: A first functional module, wherein the first functional module is used to implement a predetermined function in a specific scenario; a second functional module, which has the same function as the first functional module but is implemented in a different manner; A security storage module, used for storing a flag bit, wherein the flag bit has a set state and a cleared state; An authority control module is used to read the flag bit and convert the flag bit into boot configuration information in the memory; The initialization module is used to convert the boot configuration information into attribute information for storage, and load the corresponding first function module or second function module according to the attribute information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the multi-scenario function adaptation method according to any one of claims 1 to 7 is implemented.

10. A readable storage medium, characterized in that: The method comprises storing computer-executable instructions, wherein the computer-executable instructions are used to execute the multi-scenario function adaptation method according to any one of claims 1 to 7.

Images