Access permission determination method and device, vehicle and computer readable storage medium
By dynamically determining the access permissions of ADB in the application software, and storing information based on the version type and memory, the problem of fixed default values for the access permissions of debugging tools is solved, improving security and development efficiency.
Patent Information
- Application Number
- CN202411879865.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-19
- Publication Date
- 2025-04-25
AI Technical Summary
In the prior art, the access permissions of the application software debugging tool ADB are fixed in default values, resulting in security risks in release versions and inefficient in development and testing.
By determining its version type when the target application software is running, and dynamically determining the access permissions of ADB based on memory storage information, ensuring that the release version restricts external access, while the test version allows debugging tools to access.
Improves the security of application software, reduces the risk of external attacks, and improves the efficiency and flexibility of software development and testing.
Smart Images

Figure CN119885115A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of application software technology, and more specifically, to a method, device, vehicle and computer-readable storage medium for determining access rights in the field of application software technology. Background Art
[0002] Android Debug Bridge (ADB) is an application debugging tool. In software development and testing practice, if a fixed default value strategy is adopted for ADB access rights in the same software development branch, then no matter the compiled result is a User version or a non-User version, the ADB switch status in the version will directly use the preset default value. For example, if the default value is on, the ADB access rights will be opened to the car system after the version is actually released, which poses a greater security risk; if the default value is off, ADB needs to be manually turned on in actual use, which makes the debugging efficiency of the application software low. Summary of the invention
[0003] The present application provides a method, device, vehicle and computer-readable storage medium for determining access rights, which can improve the security of application software and improve the efficiency and flexibility of software development and testing.
[0004] In a first aspect, a method for determining access rights is provided, the method comprising:
[0005] When the target application software is running, determining the version type of the target application software;
[0006] In a case where the version type of the target application software is a release version type, determining that the target application software does not have access rights to a preset debugging tool;
[0007] In the case that the version type of the target application software is a test version type, obtaining the memory storage information currently corresponding to the target application software;
[0008] Based on the memory storage information, it is determined whether the target application software has access rights to the preset debugging tool.
[0009] The beneficial effects brought about by the technical solution of the first aspect above include at least: for the release version type (version for end users), limiting external access to the preset debugging tool helps to prevent malicious software or attackers from performing illegal operations, tampering or obtaining sensitive data through the interface of the preset debugging tool, which can effectively improve the security of the device and reduce the risk of external attacks. In the test version type, allowing access to the preset debugging tool can facilitate development and debugging work and improve development efficiency. The above scheme can dynamically determine the access rights of the debugging tool according to the actual usage scenario and real-time needs by determining the version type of the target application software and the secondary determination of the current memory storage information, thereby improving the efficiency and flexibility of software development and testing while improving the security of the application software.
[0010] In some possible implementations, the determining, based on the memory storage information, whether the target application software has access rights to the preset debugging tool includes:
[0011] In the case where the memory storage information is a first preset value, determining that the target application software has access rights to a preset debugging tool;
[0012] In the case where the memory storage information is the second preset value, it is determined that the target application software does not have the access rights of the preset debugging tool, and the first preset value is different from the second preset value.
[0013] Through the technical solution in the above possible implementation, the first preset value and the second preset value are used to control the access of the preset debugging tool, ensuring that only authorized personnel can debug the system in the development or test environment, which can effectively prevent hackers or illegal devices from exploiting the vulnerabilities of the preset debugging tool to perform malicious operations, effectively protecting a large amount of sensitive information that may be contained, and reducing the risk of data leakage. In addition, the preset debugging tool can be used to directly modify the system configuration or adjust parameters. By restricting access, it can ensure that the relevant parameters of the target application software are only modified in an authorized environment, avoiding misoperation that causes performance degradation or functional failure of the target application software.
[0014] In some possible implementations, the test version type and the release version type are different version types compiled and generated by using differentiated version attribute information in the same software development branch.
[0015] Through the technical solutions in the above possible implementation methods, the same software development branch is used to manage multiple version types during the software development process, which can reduce the complexity of branch management. The relevant development team does not need to manage multiple branches, avoiding the merging and synchronization problems between multiple branches and reducing the possibility of code merging conflicts. In addition, by working on the same development branch, all functions and fixes are based on the same code base, avoiding code differences caused by different versions of function implementation or fixes when developing in multiple branches, ensuring consistency between versions, and accelerating the efficiency of development, testing, and maintenance.
[0016] In some possible implementations, determining the version type of the target application software includes:
[0017] Obtaining version attribute information of the target application software;
[0018] If the version attribute information is the first preset parameter, determining that the version type of the target application software is the test version type;
[0019] If the version attribute information is the second preset parameter, it is determined that the version type of the target application software is the release version type, and the first preset parameter is different from the second preset parameter.
[0020] Through the technical solutions in the above possible implementations, it is possible to automatically identify whether the target application software is a test version or a release version when the application is started. This automatic identification reduces the workload of developers and testers who need to manually set or check the version type before each deployment or operation, thereby effectively improving the testing efficiency of the target application software.
[0021] In some possible implementations, the step of obtaining the memory storage information currently corresponding to the target application software includes:
[0022] The historical memory storage information corresponding to the target application software before it was last closed is used as the current memory storage information corresponding to the target application software.
[0023] Through the technical solutions in the above possible implementations, by recording the preset debugging tool switch status before closing the application and directly restoring the status at the next startup, the tester does not need to manually enable the preset debugging tool function again after each restart of the system or application. This makes the debugging and testing workflow more efficient and shortens the time wasted on repeatedly adjusting the environment during multiple debugging iterations.
[0024] In some possible implementations, the method further includes:
[0025] In the case where the memory storage information is the first preset value, if a first modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to a second preset value;
[0026] In the case where the memory storage information is the second preset value, if a second modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to the first preset value.
[0027] Through the technical solutions in the above possible implementation methods, triggering the first modification instruction and the second modification instruction can flexibly switch between different states (the first preset value and the second preset value) to meet the diverse needs during testing or operation. Relevant developers or debuggers can switch the preset debugging tool permissions on or off at any time during testing without restarting the application; and there is no need to rely on complex configuration processes or system restarts, and the state adjustment can be completed by directly detecting the modification instruction, which improves the convenience of operation.
[0028] In some possible implementations, the preset debugging tool is the Android Debug Bridge ADB.
[0029] Through the technical solutions in the above possible implementation methods, ADB can provide powerful debugging functions for relevant developers or testers to improve development efficiency, system stability and security. Through ADB, relevant developers or testers can debug applications, obtain logs, and execute commands in real time, simplify the debugging process, and improve the efficiency of software development, testing, and release. In particular, for scenarios such as car systems and smart devices that require frequent debugging and rapid iteration, ADB can effectively improve debugging efficiency.
[0030] In a second aspect, a device for determining access rights is provided, the device comprising:
[0031] A first determination module, used to determine the version type of the target application software when the target application software is running;
[0032] A second determination module is used to determine that the target application software does not have access rights to a preset debugging tool when the version type of the target application software is a release version type;
[0033] An acquisition module, used for acquiring the memory storage information currently corresponding to the target application software when the version type of the target application software is a test version type;
[0034] The third determination module is used to determine whether the target application software has the access rights of the preset debugging tool based on the memory storage information.
[0035] A third aspect provides a vehicle, comprising:
[0036] A memory for storing executable program codes;
[0037] A processor is used to call and run the above-mentioned executable program code from the above-mentioned memory, so that the above-mentioned vehicle executes the method in the above-mentioned first aspect or any possible implementation of the first aspect.
[0038] In a fourth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method in the first aspect or any possible implementation of the first aspect.
[0039] In a fifth aspect, a computer-readable storage medium is provided, which stores a computer program code. When the computer program code runs on a computer, the computer executes the method in the above-mentioned first aspect or any possible implementation manner of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Figure 1 is a schematic flow chart of a method for software compilation in a related art provided in an embodiment of the present application;
[0041] Figure 2 is an exemplary system architecture diagram of a method for determining access rights provided in an embodiment of the present application;
[0042] Figure 3 It is a flowchart of a method for determining access rights provided in an embodiment of the present application;
[0043] Figure 4 It is a flowchart of a method for determining access rights provided in an embodiment of the present application;
[0044] Figure 5 It is a flowchart of a method for determining access rights provided in an embodiment of the present application;
[0045] Figure 6 is a structural block diagram of an access authority determination device provided in an embodiment of the present application;
[0046] Figure 7 It is a structural schematic diagram of a vehicle provided in an embodiment of the present application. DETAILED DESCRIPTION
[0047] The technical solution in the present application will be described clearly and in detail below in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.
[0048] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.
[0049] In the related technology, the Android system's ADB (Android Debug Bridge) is a point-to-point communication tool between the client and the server. Usually, a computer is used as the client and an Android device is used as the server. Its access permission switch can be configured according to needs. In the officially released software version, in order to ensure system security and prevent malicious attacks, the ADB access permission must be turned off by default; in daily development and testing, in order to facilitate the use of debugging tools and test automation, the ADB access permission needs to be turned on by default. However, under the current technical solution, the same software development branch can only compile and generate a version with a fixed ADB access status, such as Figure 1 If you need to compile a first software version with the preset debugging tool ADB permission turned on and a second software version with the preset debugging tool ADB permission turned off, you need to compile through software development branch A and software development branch B respectively to set the default configuration of the preset debugging tool ADB to on and off respectively. In this way, the preset debugging tool ADB switch depends on the default configuration and cannot be flexibly and dynamically adjusted according to needs. If it is turned on by default, it will cause security risks in the listed version; if it is turned off by default, it must be manually enabled during development and testing, and it will return to the default off state after the system is restarted, which is not only cumbersome to operate but also not conducive to automated testing. This problem makes it difficult to strike a balance between security and development convenience, forming a limitation of the existing technology.
[0050] Therefore, an embodiment of the present application provides a method for determining access rights to solve the technical problems of security risks and low usage efficiency that may be caused by the above-mentioned fixed default value policy for access rights of debugging tools.
[0051] Figure 2 It is an exemplary system architecture diagram of a method for determining access rights provided in an embodiment of the present application.
[0052] like Figure 2 As shown, the system architecture may include a vehicle 201, a network 202, and a server 203. The network 202 is used to provide a medium for a communication link between the vehicle 201 and the server 203. The network 202 may include various types of wireless communication links, such as a near field communication link (NFC), an ultra wideband communication link (Ultra WideBand, UWB), a Bluetooth communication link, a wireless fidelity (Wi-Fi) communication link, or a microwave communication link.
[0053] The vehicle 201 can interact with the server 203 through the network 202 to receive messages from the server 203 or send messages to the server 203, or the vehicle 201 can interact with the server 203 through the network 202 to receive messages or data sent to the server 203 by other users. The server 203 can be a business server that provides various services. It should be noted that the server 203 can be hardware or software. When the server 203 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or it can be implemented as a single server. When the server 203 is software, it can be implemented as multiple software or software modules (for example, used to provide distributed services), or it can be implemented as a single software or software module, which is not specifically limited here.
[0054] In the embodiment of the present application, the vehicle 201 includes a vehicle computer, which is a human-computer interaction and infotainment terminal inside the vehicle 201, and can be located on the center console of the vehicle 201, and is used to provide navigation, multimedia playback, vehicle status information display, voice assistant, and application ecosystem access functions for the driver and passengers. The vehicle computer can be based on any of a variety of underlying operating system platforms (such as Android, Linux, etc.). Taking the vehicle computer based on the Android system as an example, the Android application software running or installed on the vehicle computer can access the relevant data and functions of the vehicle 201 through the hardware and software interfaces of the vehicle computer, providing users with a unique in-vehicle experience.
[0055] In the embodiment of the present application, a preset debugging tool, such as ADB, may be installed in the server 203. Relevant developers or testers may interact with the vehicle computer through ADB to execute debugging instructions, install or uninstall applications, view system logs, execute automated testing instructions, etc. Specifically, during the testing and debugging phase, relevant developers or testers may manage and debug Android application software in the vehicle computer that has the ADB access rights through ADB.
[0056] It should be understood that Figure 2The number of vehicles, networks, and servers in the figure is only illustrative, and any number of vehicles, networks, and servers may be used according to implementation requirements.
[0057] See also Figure 3 , Figure 3 A flowchart of a method for determining access rights provided in an embodiment of the present application. The execution subject of the embodiment of the present application can be a vehicle that executes the method for determining access rights, or a vehicle computer in a vehicle that executes the method for determining access rights, or a processor in a vehicle that executes the method for determining access rights, or an access rights determination service in a vehicle that executes the method for determining access rights. For ease of description, the specific execution process of the method for determining access rights is introduced below, taking the vehicle computer in a vehicle as an example.
[0058] like Figure 3 As shown, the access authority determination method may at least include the following S301-S304:
[0059] S301: When the target application software is running, determine the version type of the target application software.
[0060] Optionally, the target application software may be any application software installed in the vehicle computer, the vehicle computer may be based on an Android operating system, and the target application software is an Android application software. Specifically, in the vehicle computer, the target application software may be a navigation application, a media player application, or other vehicle-specific application software.
[0061] Optionally, the version type of the target application software refers to the version classification corresponding to different release stages or uses of the software, which may specifically include release version types and test version types. Among them, the release version type is a version type that is oriented to end users, has been fully tested and optimized, and is suitable for formal release and use. The test version type is used in the development, debugging and testing stages, and may contain new functions, experimental features, or codes that are not yet completely stable. Furthermore, the test version type may include debug, engineering debugging eng version types, etc. debug is a version specially designed for the development and debugging stages, which may include many debugging functions, such as detailed log output, performance analysis tools, memory debugging, etc., to help developers quickly locate problems; the eng version type is similar to the debug version, but may be closer to the final product in terms of function, and includes some tools or functions in the engineering stage.
[0062] Optionally, when the target application is running, identifying and confirming whether the version currently used by the application is a release version or a test version can be achieved by checking the internal identification or configuration file of the application or querying version information through a specific interface.
[0063] S302: When the version type of the target application software is a release version type, determine that the target application software does not have access rights to a preset debugging tool.
[0064] Optionally, the preset debugging tool is a tool used to help developers detect, analyze, troubleshoot and fix problems or errors in the program during the software development process. The preset debugging tool provides a variety of functions, allowing developers to deeply understand the running status of the application, debug code, capture and view error logs, analyze performance, etc.
[0065] Specifically, the above-mentioned preset debugging tool can be Android Debug Bridge ADB, or any other debugging tool in the relevant technology, and this application does not make specific limitations on this.
[0066] The above ADB can provide powerful debugging functions for relevant developers or testers to improve development efficiency, system stability and security. Through ADB, relevant developers or testers can debug applications, obtain logs, and execute commands in real time, simplify the debugging process, and improve the efficiency of software development, testing, and release. Especially for scenarios such as car systems and smart devices that require frequent debugging and rapid iteration, ADB can effectively improve debugging efficiency.
[0067] Optionally, when the version type of the target application software is a release version type, it is determined that the target application software does not have access rights to preset debugging tools. That is, the target application software does not allow developers or other external personnel to access debugging tools or debugging interfaces in the release version to improve the security and stability of the target application software.
[0068] S303: When the version type of the target application software is a test version type, obtain the memory storage information currently corresponding to the target application software.
[0069] Optionally, the memory storage information refers to a variable or flag value stored in the device, which is used to indicate a permission access switch or flag bit of a preset debugging tool, specifically indicating whether the target application software has the access rights of the preset debugging tool. The memory storage information can be stored in the memory or storage space used by the target application software.
[0070] S304: Determine whether the target application software has access rights to the preset debugging tool based on the memory storage information.
[0071] In the case where the version type of the target application software is a test version type, it is necessary to further determine whether the target application software has access rights to the preset debugging tool through the memory storage information of the target application software to determine whether the target application software can use the preset debugging tool. If the memory storage information meets the predetermined conditions, the debugging tool is allowed to be used; if it does not meet the conditions, the debugging tool is not allowed to be used, thereby improving the security and stability of the target application software.
[0072] In the embodiment of the present application, by determining the version type of the target application software when the target application software is running; when the version type of the target application software is a release version type, determining that the target application software does not have the access rights of the preset debugging tool; when the version type of the target application software is a test version type, obtaining the memory storage information currently corresponding to the target application software; based on the memory storage information, determining whether the target application software has the access rights of the preset debugging tool. For the release version type (version for end users), restricting external access to the preset debugging tool helps to avoid malicious software or attackers from illegally operating, tampering or obtaining sensitive data through the interface of the preset debugging tool, which can effectively improve the security of the device and reduce the risk of external attacks. In the test version type, allowing access to the preset debugging tool can facilitate development and debugging work and improve development efficiency. The above scheme can dynamically determine the access rights of the debugging tool according to the actual use scenario and real-time needs through the determination of the version type of the target application software and the secondary determination of the current memory storage information, while improving the security of the application software, it improves the efficiency and flexibility of software development and testing.
[0073] See also Figure 4 , Figure 4 A flowchart of a method for determining access rights provided in an embodiment of the present application.
[0074] like Figure 4 As shown, the access authority determination method may include S401-S405:
[0075] S401. When the target application software is running, obtain version attribute information of the target application software.
[0076] Optionally, the version attribute information may be various information related to the target application software version, which may help identify the version characteristics of the application. The version attribute information may specifically include: version number, version identifier (such as debug), and the like.
[0077] Specifically, the version attribute information may be a version attribute key value Key.
[0078] Optionally, in Android application software, the version attribute information of the target application software can be obtained through the application manager PackageManager or other methods.
[0079] S402: If the version attribute information is the first preset parameter, determine that the version type of the target application software is the test version type.
[0080] Optionally, the first preset parameter may be a preset identifier or parameter value, which is used to identify the application software of the test version type.
[0081] S403: If the version attribute information is the second preset parameter, determine that the version type of the target application software is the release version type, and the first preset parameter is different from the second preset parameter.
[0082] Optionally, the second preset parameter refers to another preset parameter different from the first preset parameter, and is used to identify the release version type of the application software.
[0083] For example, in a software development scenario, developers define several versions during the development process, and use the first preset parameter and the second preset parameter to mark whether the application software is a test version type or a release version type.
[0084] It is understandable that, in addition to the first preset parameter and the second preset parameter, other parameters may also be used to represent other version types in addition to the test version type and the release version type.
[0085] By judging the version attribute information, it can automatically identify whether the target application software is a test version or a release version when the application is started. This automatic identification reduces the workload of developers and testers who need to manually set or check the version type before each deployment or operation, thereby effectively improving the testing efficiency of the target application software.
[0086] S404: When the version type of the target application software is a release version type, determining that the target application software does not have access rights to a preset debugging tool;
[0087] S405: when the version type of the target application software is a test version type, obtaining the memory storage information currently corresponding to the target application software;
[0088] S406: Determine whether the target application software has access rights to the preset debugging tool based on the memory storage information.
[0089] For the specific process of S404-S406, please refer to the detailed records in S302-S304, which will not be repeated here.
[0090] Optionally, the above-mentioned test version type and the above-mentioned release version type are different version types generated by compiling differentiated version attribute information in the same software development branch. In the development and testing activities of the target application software, for a certain software development branch, the default configuration of the access rights of the preset debugging tool is set to the closed state. Specifically, when the software development branch is integrated and compiled, the corresponding test version type (i.e., non-User version) and release version type (i.e., User version) are generated according to different software version requirements. During the operation of the target application software, two persistent storage values can be generated and maintained, namely, version attribute information and memory storage information. For the release version type, the access rights of the preset debugging tool will be strictly configured according to the preset default value (closed) to improve the security and stability of the user end. For the test version type, the final state of the access rights of the preset debugging tool will be determined based on the second persistent value-memory storage information to meet the needs of development and testing.
[0091] Optionally, in addition to simply turning it on or off, you can also add multiple levels of policies for the permission control of the preset debugging tool. For example, provide different permission policies for the development level, test level, and production level, with different access control settings at each level. In this way, you can manage permissions between different version types in a more refined manner, preventing developers or testers from accidentally or maliciously modifying permission settings in the production environment.
[0092] In the embodiment of the present application, the same software development branch is used to manage multiple version types (including test version types and release version types) during software development. Compared with using two independent development branches, the complexity of branch management can be reduced. The relevant development team does not need to manage multiple branches, avoiding the merging and synchronization problems between multiple branches, and reducing the possibility of code merging conflicts, which is particularly beneficial for small teams or projects that frequently release updates. In addition, by working on the same development branch, all functions and repairs are based on the same code base, avoiding the code differences caused by different versions of function implementation or repair when developing in multiple branches, and ensuring the consistency between versions. In addition, the relevant developers do not need to frequently switch branches or do repeated work. All functions and repairs are carried out in one place. Development and testing personnel can quickly iterate code and debug in the same branch without waiting for merging code or switching branches, thereby speeding up the efficiency of development and testing. During software maintenance, the relevant maintenance team only needs to maintain a code base, reducing the workload of maintaining multiple branch codes, which is conducive to improving the maintenance efficiency of the software.
[0093] Optionally, in the above S303, the above obtaining the memory storage information currently corresponding to the above target application software includes: using the historical memory storage information corresponding to the above target application software before it was last closed as the memory storage information currently corresponding to the above target application software.
[0094] Optionally, the memory storage information value records the current state of the preset debugging tool switch during the operation of the target application software, so that the vehicle computer can be restored to the state before the last shutdown when it is restarted next time. For example, if the tester turns on the preset debugging tool function during the test, the memory storage value will maintain this state to ensure that the preset debugging tool is still turned on after the system restarts. For test version types, the memory storage value is set to the on state by default and is persistently stored in a database to facilitate frequent adjustment of preset debugging tool permissions during development and debugging.
[0095] Optionally, after the target application software device is abnormal or powered off and restarted, the preset debugging tool permission state can also be automatically restored. For example, after the device is restarted, the preset debugging tool permission can be restored to the state set by the last user, or restored to the default security state.
[0096] Optionally, relevant developers or testers can conveniently set the access rights of preset debugging tools for different application software or devices through the User Interface (UI). Specifically, the switch of preset debugging tool access rights can be customized according to the role, device type, and operation requirements. For example, the access rights switch of preset debugging tools can be configured by time period, so that access rights are enabled during preset development working hours, and access rights are automatically disabled during non-preset working hours.
[0097] In the embodiment of the present application, by recording the preset debugging tool switch status before closing the application and directly restoring the status at the next startup, the tester does not need to manually enable the preset debugging tool function again after each restart of the system or application. This makes the debugging and testing workflow more efficient and shortens the time wasted on repeatedly adjusting the environment during multiple debugging iterations.
[0098] Optionally, with respect to the modification of the above-mentioned memory storage information, the above-mentioned method further comprises:
[0099] In the case where the memory storage information is the first preset value, if a first modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to the second preset value. In the case where the memory storage information is the second preset value, if a second modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to the first preset value.
[0100] Optionally, the first preset value and the second preset value are used to describe two different states of the memory storage information. Specifically, the memory storage information may represent the switch state of the access permission of the preset debugging tool, the first preset value represents the on state, and the second preset value represents the off state.
[0101] Optionally, the first modification instruction and the second modification instruction are used to trigger the update of the memory storage information. The first modification instruction and the second modification instruction may be derived from a user operation (such as clicking a button), a system internal logic trigger (such as automatic switching after a certain condition is met), or an external signal input. After the corresponding modification instruction is detected, the memory storage information may be modified according to the current state of the memory storage information and the preset logic rules.
[0102] Specifically, the first modification instruction is used to instruct to modify the memory storage information from the first preset value to the second preset value, and the second modification instruction is used to instruct to modify the memory storage information from the second preset value to the first preset value.
[0103] Optionally, when a modification instruction is triggered according to a user operation, a multiple identity authentication mechanism can be introduced to ensure that only strictly authenticated users can adjust permissions. Among them, multiple authentications can include passwords, fingerprints, facial recognition, and the like. For example, when the first modification instruction or the second modification instruction is triggered, it is required to enter a password and perform a secondary identity authentication (such as a text message verification code, fingerprint recognition, etc.), or combine the device's biometric capabilities (such as fingerprints, facial recognition) to strengthen permission management, and only users who have undergone biometrics can trigger the modification instruction. Through multi-level identity authentication, unauthorized users or malicious users can effectively prevent illegal operations or tampering with the access rights of the preset debugging tool. Only strictly authenticated users can execute it, which effectively improves the security and reliability of the use of the preset debugging tool.
[0104] Optionally, the first modification instruction and / or the second modification instruction may be automatically triggered according to the state of the device (such as the vehicle computer) running the target application software (such as the driving state of the vehicle in which the vehicle computer is located). For example, in the vehicle computer, when the vehicle in which the vehicle computer is located is in a driving state, if it is detected that the current memory storage information is a first preset value, the first modification instruction may be automatically triggered to automatically close the access rights of the preset debugging tool to avoid unnecessary operations and potential risks, avoid debugging or operations during driving, and improve driving safety.
[0105] Optionally, the first modification instruction and the second modification instruction may be automatically triggered according to the network environment of the device (such as the vehicle computer) running the target application software. For example, when connected to a trusted local area network (such as an internal corporate network), more permission access may be allowed, and when connected to a public Wi-Fi or an unknown network, if it is detected that the current memory storage information is the first preset value, the first modification instruction may be automatically triggered to automatically limit the access to the ADB permission.
[0106] In addition, the permission control can be further refined according to factors such as the type of device where the target application is located, the user role using the target application, the application status, etc., so as to decide whether to enable the permission of the debugging tool based on a combination of different dimensions.
[0107] Optionally, if the version type of the target application software also includes other version types besides the test version type and the release version type, other corresponding modification instructions may be triggered to modify the memory storage information to preset values corresponding to other version types. Each preset value may correspond to a different version type of the target application software, so that the user can flexibly set the permission level of different version types.
[0108] In the embodiment of the present application, by triggering the first modification instruction and the second modification instruction, it is possible to flexibly switch between different states (the first preset value and the second preset value) to meet the diverse needs during testing or operation. For example, relevant developers or debuggers can switch the ADB permission on or off at any time during testing without restarting the application; and there is no need to rely on complex configuration processes or system restarts, and the state adjustment can be completed by directly detecting the modification instruction, which improves the convenience of operation.
[0109] Optionally, in the above S304, the above determining whether the above target application software has access rights to the above preset debugging tool based on the above memory storage information includes S3041-S3042:
[0110] S3041. When the memory storage information is a first preset value, determine that the target application software has access rights to a preset debugging tool.
[0111] S3042: When the memory storage information is a second preset value, it is determined that the target application software does not have access rights to a preset debugging tool, and the first preset value is different from the second preset value.
[0112] Optionally, the first preset value is a specific value, indicating that the target application software has the permission to access the debugging tool, such as a Boolean value of 1 or other specific flag value; the second preset value is another specific value, different from the first preset value, indicating that the target application does not have the permission to access the debugging tool, such as a Boolean value of 0.
[0113] For example, modern car entertainment systems or navigation systems use the Android operating system. Relevant developers or testers may need to use ADB tools to debug relevant target application software, such as checking application logs, analyzing performance, or debugging specific functional modules. In this scenario, if the memory storage information of the target application software to be debugged is the first preset value, the vehicle system allows access to the on-board Android system through ADB. Relevant developers or testers can obtain system logs, debug applications, or perform software upgrades through ADB commands. If the memory storage information is the second preset value, access to the on-board Android system through the ADB tool is prohibited, and the target application software cannot be debugged through ADB, thereby avoiding unauthorized debugging and effectively improving the security of the target application software.
[0114] In the embodiment of the present application, the ADB access is controlled by using the first preset value and the second preset value to ensure that only authorized personnel can debug the system in the development or test environment, which can effectively prevent hackers or illegal devices from using ADB vulnerabilities to perform malicious operations, such as tampering with the vehicle system or stealing data, etc., effectively protecting a large amount of sensitive information that may be contained (such as user data, driving records, GPS tracks, etc.), and reducing the risk of data leakage. In addition, ADB can be used to directly modify system configurations or adjust parameters. By restricting access, it can ensure that the vehicle's parameters are only modified in an authorized environment, avoiding misoperation that causes vehicle performance degradation or functional failure.
[0115] In some embodiments, ADB permissions can also be automatically adjusted after certain abnormal behaviors are detected. For example, if it is detected that an application software that does not have access to the preset debugging tool frequently attempts to connect through ADB, the ADB permissions can be immediately disabled to prevent potential malicious attacks. Specifically, if an application software sends more than a preset number of ADB connection requests within a preset time period, the ADB permissions can be immediately disabled and the behavior can be recorded for later auditing.
[0116] In some embodiments, in order to improve the transparency and traceability of permission management, each access to a preset debugging tool, access permission modification and other operations can be recorded, and a detailed security audit report can be generated to help the operation and maintenance team monitor the security status of the system in real time and discover potential security issues. Specifically, each operation of modifying, enabling or disabling the access rights of a preset debugging tool can be recorded, including information such as the time of the operation, the operator, and the operating device.
[0117] The following combination Figure 5 This application is described. Figure 5A flowchart of a method for determining access rights provided in an embodiment of the present application. Figure 5 , the access authority determination method includes S501-S507:
[0118] S501. When the target application software is running, obtain version attribute information of the target application software.
[0119] S502: Determine whether the version attribute information is the first preset parameter. If yes, execute S503; if no, execute S506.
[0120] Optionally, the version attribute information is a first preset parameter or a second preset parameter. When it is determined that the version attribute information is not the first preset parameter, it can be determined that the version attribute information is the second preset parameter.
[0121] S503: Determine that the version type of the target application software is a test version type.
[0122] Optionally, the specific process of S501-S503 is consistent with the above-mentioned S401-S403, and will not be repeated here.
[0123] S504: Determine whether the memory storage information is a first preset value. If yes, execute S505; if no, execute S507.
[0124] Optionally, the memory storage information is a first preset value or a second preset value. When it is determined that the memory storage information is not the first preset value, it can be determined that the memory storage information is the second preset value.
[0125] S505: Determine whether the target application software has access rights to a preset debugging tool.
[0126] S506: Determine that the version type of the target application software is a release version type.
[0127] S507: Determine that the target application software does not have access rights to the preset debugging tool.
[0128] Optionally, the specific process of S504-S507 is consistent with the above-mentioned S3041-S3042, and will not be repeated here.
[0129] In the embodiment of the present application, by judging the version attribute information and memory storage information of the target application software, the access rights of the debugging tool can be flexibly determined. For example, in the development or testing scenario (test version type), allowing the target application software to access the debugging tool helps to quickly identify and fix vulnerabilities in the application, improve development efficiency, and thus launch products that meet quality standards more quickly; while in the release version type, the use of the debugging tool is prohibited, which can effectively prevent unauthorized personnel from tampering with the system through the debugging tool and reduce the risk of the system being attacked by hackers; prohibiting the use of debugging tools in the release version can prevent the system from being modified by malicious personnel through the debugging tool or obtaining sensitive data, thereby improving the anti-attack capability of the target application software.
[0130] The following describes this solution in combination with specific usage scenarios. Taking the car computer based on the Android system as an example, during the development stage of the car computer application software, the relevant developers choose to use the target application software of the test version type, that is, the non-User version, during the debugging process, and the system enables ADB access rights by default. The relevant developers can communicate with the car computer through the preset debugging tools to facilitate functional verification and performance testing. During the integration test phase, the relevant testers may turn off the ADB access rights to enhance the security of the system. At this time, the testers can manually turn on or off the ADB permissions through the system settings. When the target application software is ready to be released to consumers, the target application software compiled as the release version type (that is, the User version) can be released to consumers. The ADB access rights of the target application software of the release version type are closed by default and cannot be easily modified by external devices or users. In this way, even if the device is connected to an external computer, it cannot be debugged or the device settings cannot be modified through ADB, thereby preventing malicious attacks and effectively improving the security and reliability of the application software operation.
[0131] See also Figure 6 , Figure 6 This is a structural block diagram of a device for determining access rights provided in an embodiment of the present application. Figure 6 As shown, the access authority determining device 600 includes:
[0132] A first determination module 610 is used to determine the version type of the target application software when the target application software is running;
[0133] The second determination module 620 is used to determine that the target application software does not have the access rights of the preset debugging tool when the version type of the target application software is a release version type;
[0134] The acquisition module 630 is used to acquire the memory storage information currently corresponding to the target application software when the version type of the target application software is a test version type;
[0135] In some embodiments, the third determination module 640 is used to determine whether the target application software has the access rights of the preset debugging tool based on the memory storage information.
[0136] In some embodiments, the third determination module 640 includes:
[0137] A first determining unit, configured to determine, when the memory storage information is a first preset value, that the target application software has access rights to a preset debugging tool;
[0138] The second determining unit is used to determine that the target application software does not have the access rights of the preset debugging tool when the memory storage information is a second preset value, and the first preset value is different from the second preset value.
[0139] In some embodiments, the test version type and the release version type are different version types compiled and generated by using differentiated version attribute information in the same software development branch.
[0140] In some embodiments, the first determining module 610 includes:
[0141] A first acquisition unit, used to acquire version attribute information of the target application software;
[0142] A third determining unit, configured to determine that the version type of the target application software is the test version type when the version attribute information is the first preset parameter;
[0143] The fourth determining unit is used to determine that the version type of the target application software is the release version type when the version attribute information is the second preset parameter, and the first preset parameter is different from the second preset parameter.
[0144] In some embodiments, the acquisition module 630 includes:
[0145] The fifth determining unit is used to use the historical memory storage information corresponding to the target application software before it was last closed as the memory storage information currently corresponding to the target application software.
[0146] In some embodiments, the apparatus 600 further includes:
[0147] A first modification module is used for modifying the memory storage information to a second preset value if a first modification instruction for the memory storage information currently corresponding to the target application software is detected when the memory storage information is the first preset value;
[0148] The second modification module is used to modify the memory storage information to the first preset value if a second modification instruction for the memory storage information currently corresponding to the target application software is detected when the memory storage information is the second preset value.
[0149] In some embodiments, the default debugging tool is the Android Debug Bridge ADB.
[0150] In this embodiment, the functional modules of the device can be divided according to the above method example. For example, each functional module can be corresponded, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware. It should be noted that the division of modules in this embodiment is schematic and is only a logical function division. There may be other division methods in actual implementation.
[0151] It should be understood that the device provided in this embodiment is used to execute the above-mentioned access authority determination method, and thus can achieve the same effect as the above-mentioned implementation method.
[0152] In the case of an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module may be used to control and manage the actions of the vehicle. The storage module may be used to support the vehicle in executing related program codes, etc.
[0153] The processing module may be a processor or a controller, which may implement or execute various exemplary logic blocks, modules and circuits shown in conjunction with the disclosure of the present application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc. The storage module may be a memory.
[0154] In addition, the device provided in the embodiments of the present application may specifically be a chip, component or module, and the chip may include a connected processor and memory; wherein the memory is used to store instructions, and when the processor calls and executes the instructions, the chip can execute a method for determining access rights provided in the above embodiments.
[0155] See also Figure 7 , Figure 7 A schematic diagram of the structure of a vehicle provided in an embodiment of the present application. Figure 7 As shown, the vehicle 700 may include: at least one vehicle processor 701 , at least one network interface 704 , a user interface 703 , a memory 705 , and at least one communication bus 702 .
[0156] The communication bus 702 is used to realize the connection and communication between these components.
[0157] The user interface 703 may include a display screen (Display) and a camera (Camera), and the optional user interface 703 may also include a standard wired interface and a wireless interface.
[0158] The network interface 704 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).
[0159] Among them, the vehicle processor 701 may include one or more processing cores. The vehicle processor 701 uses various interfaces and lines to connect various parts of the entire vehicle 700, and executes various functions and processes data of the vehicle 700 by running or executing instructions, programs, code sets or instruction sets stored in the memory 705, and calling data stored in the memory 705. Optionally, the vehicle processor 701 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The vehicle processor 701 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the vehicle processor 701, and it can be implemented separately through a chip.
[0160] The memory 705 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 705 includes a non-transitory computer-readable storage medium. The memory 705 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 705 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned method embodiments, etc.; the data storage area may store data involved in the above-mentioned method embodiments, etc. The memory 705 may optionally be at least one storage device located away from the aforementioned vehicle processor 701. As Figure 7 As shown, the memory 705 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an access authority determination program.
[0161] exist Figure 7 In the vehicle 700 shown, the user interface 703 is mainly used to provide an input interface for the user and obtain data input by the user; and the vehicle processor 701 can be used to call the access authority determination program stored in the memory 705, and specifically perform the following operations:
[0162] When the target application software is running, determining the version type of the target application software;
[0163] In a case where the version type of the target application software is a release version type, determining that the target application software does not have access rights to a preset debugging tool;
[0164] In the case that the version type of the target application software is a test version type, obtaining the memory storage information currently corresponding to the target application software;
[0165] Based on the memory storage information, it is determined whether the target application software has access rights to the preset debugging tool.
[0166] In some embodiments, when the vehicle processor 701 determines whether the target application software has the access rights of the preset debugging tool based on the memory storage information, the vehicle processor 701 specifically performs the following steps:
[0167] In the case where the memory storage information is a first preset value, determining that the target application software has access rights to a preset debugging tool;
[0168] In the case where the memory storage information is the second preset value, it is determined that the target application software does not have the access rights of the preset debugging tool, and the first preset value is different from the second preset value.
[0169] In some embodiments, the test version type and the release version type are different version types compiled and generated by using differentiated version attribute information in the same software development branch.
[0170] In some embodiments, when the vehicle processor 701 determines the version type of the target application software, it specifically performs the following steps:
[0171] Obtaining version attribute information of the target application software;
[0172] If the version attribute information is the first preset parameter, determining that the version type of the target application software is the test version type;
[0173] If the version attribute information is the second preset parameter, it is determined that the version type of the target application software is the release version type, and the first preset parameter is different from the second preset parameter.
[0174] In some embodiments, when the vehicle processor 701 executes to obtain the memory storage information currently corresponding to the target application software, it specifically performs the following steps:
[0175] The historical memory storage information corresponding to the target application software before it was last closed is used as the current memory storage information corresponding to the target application software.
[0176] In some embodiments, the vehicle processor 701 further specifically performs the following steps:
[0177] In the case where the memory storage information is the first preset value, if a first modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to a second preset value;
[0178] In the case where the memory storage information is the second preset value, if a second modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to the first preset value.
[0179] In some embodiments, the default debugging tool is the Android Debug Bridge ADB.
[0180] This embodiment also provides a computer-readable storage medium, in which a computer program code is stored. When the computer program code is executed on a computer, the computer executes the above-mentioned related method steps to implement a method for determining access rights provided in the above embodiment.
[0181] This embodiment also provides a computer program product. When the computer program product runs on a computer, it enables the computer to execute the above-mentioned related steps to implement a method for determining access rights provided by the above embodiment.
[0182] Among them, the device, computer-readable storage medium, computer program product or chip provided in this embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.
[0183] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0184] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0185] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A method for determining access rights, characterized in that: The method comprises: When the target application software is running, determining the version type of the target application software; In a case where the version type of the target application software is a release version type, determining that the target application software does not have access rights to a preset debugging tool; When the version type of the target application software is a test version type, obtaining the memory storage information currently corresponding to the target application software; Based on the memory storage information, it is determined whether the target application software has the access authority of the preset debugging tool.
2. The method according to claim 1, characterized in that The determining, based on the memory storage information, whether the target application software has the access rights of the preset debugging tool includes: In a case where the memory storage information is a first preset value, determining that the target application software has access rights to a preset debugging tool; When the memory storage information is a second preset value, it is determined that the target application software does not have access rights to a preset debugging tool, and the first preset value is different from the second preset value.
3. The method according to claim 1, characterized in that The test version type and the release version type are different version types compiled and generated by using differentiated version attribute information in the same software development branch.
4. The method according to claim 1, characterized in that: The determining the version type of the target application software includes: Obtaining version attribute information of the target application software; If the version attribute information is the first preset parameter, determining that the version type of the target application software is the test version type; If the version attribute information is the second preset parameter, it is determined that the version type of the target application software is the release version type, and the first preset parameter is different from the second preset parameter.
5. The method according to claim 1, characterized in that The obtaining of the memory storage information currently corresponding to the target application software includes: The historical memory storage information corresponding to the target application software before it was last closed is used as the current memory storage information corresponding to the target application software.
6. The method according to claim 2, characterized in that The method further comprises: In the case where the memory storage information is the first preset value, if a first modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to a second preset value; In the case where the memory storage information is the second preset value, if a second modification instruction for the memory storage information currently corresponding to the target application software is detected, the memory storage information is modified to the first preset value.
7. The method according to claim 1, characterized in that The default debugging tool is the Android Debug Bridge ADB.
8. A device for determining access rights, characterized in that: include: A first determination module, used to determine the version type of the target application software when the target application software is running; A second determination module is used to determine that the target application software does not have access rights to a preset debugging tool when the version type of the target application software is a release version type; An acquisition module, used for acquiring the memory storage information currently corresponding to the target application software when the version type of the target application software is a test version type; The third determination module is used to determine whether the target application software has the access authority of the preset debugging tool based on the memory storage information.
9. A vehicle, characterized in that: The vehicle comprises: A memory for storing executable program codes; A processor, configured to call and run the executable program code from the memory, so that the vehicle executes the method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed, the method according to any one of claims 1 to 7 is implemented.