Application access control methods, electronic devices, vehicles and storage media

Abstract

The embodiment of the application discloses an application permission management method, an electronic device, a vehicle and a storage medium. The application determines a first interface call request initiated by a target application running on a vehicle terminal for a first application programming interface. Based on a mapping relationship, the first interface call request is subjected to permission verification processing. The mapping relationship includes the correspondence between an application and at least one application programming interface that can be called by the application. In this way, according to the intelligent network connection technology, the application programming interface that the target application has the calling permission can be determined according to the preset mapping relationship. Therefore, based on the mapping relationship, the first interface call request is subjected to permission verification processing, the compatibility of the application and the vehicle machine system is improved, and the situation that the hash value of the application package is changed in the application and application programming interface authorization process, and the subsequent incremental update of the application cannot be normally performed is avoided, and the permission management efficiency of the vehicle machine application is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an application permission management method, electronic device, vehicle, and storage medium. Background Technology

[0002] In existing in-vehicle infotainment application permission management methods, key pairs are often generated through a key management system. The application release center uses the signing key in the key pair to sign the application and permissions, generating an application data package. The in-vehicle infotainment system reads the public key certificate in the key pair to verify the legality of the application signature and permission signature of the application data package. After the verification is successful, the system assigns the specified permissions to the application and completes the installation.

[0003] Research and practice on existing technologies have revealed that current in-vehicle infotainment application permission management methods can alter the hash value of application packages, leading to compatibility issues between applications and the in-vehicle infotainment system. This can also prevent subsequent incremental updates of applications from proceeding normally, increasing the cost of application permission management and the update cost of third-party in-vehicle infotainment applications, and consequently resulting in poor efficiency in the permission management of in-vehicle infotainment applications. Summary of the Invention

[0004] This application provides an application permission management method, electronic device, vehicle, storage medium, and product, which can improve the permission management efficiency of in-vehicle applications.

[0005] To achieve the above objectives, according to a first aspect of this application, an application permission management method is provided, the method comprising: Determine the first interface call request initiated by the target application running on the vehicle terminal in response to the first application programming interface; Based on the mapping relationship, the first interface call request is subject to permission verification. The mapping relationship includes the correspondence between the application and at least one application programming interface that it can call.

[0006] According to a second aspect of this application, an application permission management method is provided, the method comprising: Based on the correspondence between the applications running on the vehicle terminal and at least one application programming interface that can be called, a mapping relationship is generated for each of the applications. The mapping relationship is sent to the vehicle terminal.

[0007] According to a third aspect of this application, an application permission management device is provided, the device comprising: The determining unit is used to determine the first interface call request initiated by the target application running on the vehicle terminal in response to the first application programming interface. The authentication unit is used to perform permission verification processing on the first interface call request based on the mapping relationship, which includes the correspondence between the application and at least one application programming interface that it can call.

[0008] According to a fourth aspect of this application, an electronic device is provided, including a processor and a memory, wherein the memory stores an application program, and the processor is used to run the application program in the memory to implement the application permission management method provided in the embodiments of this application.

[0009] According to a fifth aspect of this application, a vehicle is provided, the vehicle being an electronic device as described in the fourth aspect; or, a processor is provided to perform steps in an application permission management method as described in either the first or second aspect of this application.

[0010] According to a sixth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program adapted for loading by a processor to perform steps in any of the application permission management methods provided in the embodiments of this application.

[0011] According to a seventh aspect of this application, a computer program product is provided, the computer program product including a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps in the application permission management method provided in the embodiments of this application.

[0012] In the application permission management method, electronic device, vehicle, and storage medium of this application embodiment, a first interface call request initiated by a target application running on an in-vehicle terminal for a first application programming interface is determined. Based on a mapping relationship, permission verification processing is performed on the first interface call request. The mapping relationship includes the correspondence between the application and at least one application programming interface that it can call. Thus, by determining the application programming interface that the target application has call permission based on the preset mapping relationship, permission verification processing is performed on the first interface call request based on the mapping relationship. This improves the compatibility between the application and the in-vehicle system, thereby avoiding the situation where the hash value of the application package is changed during the application and application programming interface authorization process, which could prevent subsequent incremental updates of the application from proceeding normally, and improving the permission management efficiency of in-vehicle applications. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram illustrating an implementation scenario of an application permission management method provided in this application embodiment; Figure 2 This is a flowchart illustrating an application permission management method provided in an embodiment of this application; Figure 3 This is another flowchart illustrating an application permission management method provided in an embodiment of this application; Figure 4a This is an overall system architecture diagram of an application permission management method provided in an embodiment of this application; Figure 4b This is a schematic diagram of the trust mapping database structure of an application permission management method provided in an embodiment of this application; Figure 4c This is a schematic diagram of the security authentication relay module structure of an application permission management method provided in this application embodiment; Figure 4d This is a schematic diagram illustrating the specific process of an application permission management method provided in an embodiment of this application; Figure 4e This is an interactive schematic diagram of an application permission management method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the application permission management device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0016] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0017] This application provides an application permission management method, an electronic device, a vehicle, a storage medium, and a product. The application permission management device can be integrated into an electronic device, which can be a server, a terminal, or other similar device.

[0018] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal can include, but is not limited to, in-vehicle terminals, mobile phones, computers, intelligent voice interaction devices, smart home appliances, and aircraft. The terminal and server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0019] The electronic device can be integrated into a vehicle, which can be a gasoline-powered vehicle, a plug-in hybrid electric vehicle, or a new energy vehicle, etc. This application does not make any specific limitations on this.

[0020] Please see Figure 1 Taking the integration of application permission management devices into electronic devices as an example, Figure 1 This is a schematic diagram of an implementation scenario of the application permission management method provided in this application. The electronic device can be integrated into the device or communicate with the device. The device can be a vehicle. It can determine the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface. Based on the mapping relationship, the permission verification processing of the first interface call request is performed. The mapping relationship includes the correspondence between the application and at least one application programming interface that it can call.

[0021] It should be noted that, Figure 1The illustrated scenario of the application permission management method is merely an example. The implementation environment scenario of the application permission management method described in this application embodiment is for the purpose of more clearly illustrating the technical solution of this application embodiment and does not constitute a limitation on the technical solution provided in this application embodiment. As those skilled in the art will know, with the evolution of application permission management and the emergence of new business scenarios, the technical solution provided in this application is also applicable to similar technical problems.

[0022] The solutions provided in this application are specifically illustrated through the following embodiments. It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments.

[0023] This embodiment will be described from the perspective of an application permission management device, which can be integrated into an electronic device.

[0024] Please see Figure 2 , Figure 2 This is a flowchart illustrating the application permission management method provided in an embodiment of this application. The application permission management method includes: Step 101: Determine the first interface call request initiated by the target application running on the vehicle terminal against the first application programming interface.

[0025] The target application can be the application that initiates the interface call request. The in-vehicle terminal can run a vehicle infotainment system. The target application can run on the vehicle infotainment system. The first application programming interface can be an Application Programming Interface (API) initiated by the target application. This API can be a type of in-vehicle interaction interface (AutoAPI), which refers to a custom-packaged in-vehicle interface by the Original Equipment Manufacturer (OEM) on the Android Automotive OS, used for functions such as reading vehicle status, vehicle control, navigation, and audio control. The first interface call request can be a request initiated by the target application to call the first application programming interface.

[0026] Optionally, the in-vehicle terminal can be an electronic device installed inside the vehicle for vehicle monitoring and management, and for realizing intelligent connectivity. The in-vehicle system can refer to a software system or operating system environment running on the in-vehicle terminal, used to provide a human-machine interface and vehicle function management services.

[0027] In one embodiment, the first interface call request can be an interface call request based on the inter-process communication mechanism (Binder). Binder can refer to the Android inter-process communication mechanism. The target application is a third-party application. Since the third-party application and the AutoAPI system service run in independent processes, when the third-party application needs to call the AutoAPI, it needs to initiate an interface call request to the AutoAPI system service through the Binder cross-process communication channel. In this embodiment, the permission verification can be triggered at the entry point of the Binder communication channel.

[0028] Step 102: Based on the mapping relationship, perform permission verification processing on the first interface call request.

[0029] The mapping relationship may include the correspondence between an application and at least one application programming interface that it can call.

[0030] Optionally, the application passes the compliance audit test provided by the cloud corresponding to the in-vehicle terminal.

[0031] The compliance audit and testing can include compliance audits and automated testing. The cloud can pre-test applications that need to run on the vehicle terminal for compliance audits and automated testing. This is used to audit the application's security, compatibility, privacy protection compliance, etc., to ensure that the application meets the security requirements of the vehicle system and relevant industry standards, so as to prevent malicious applications from accessing the vehicle system.

[0032] After an application passes compliance audit testing, the cloud can determine the application programming interfaces (APIs) that the application can call. It can then generate a mapping relationship based on the application and its APIs and synchronize the mapping relationship to the vehicle terminal, enabling the vehicle terminal to perform permission verification processing on the application's API call requests.

[0033] There are several ways to perform permission verification on the first interface call request based on the mapping relationship. For example, based on the application identity credential information of the target application and the mapping relationship, at least one target application programming interface that the target application has the right to call can be determined; and based on the target application programming interface, permission verification is performed on the first interface call request.

[0034] The application identity credentials information can be information indicating the identity of the target application. The target application programming interface can be an application programming interface that the target application has the authority to access.

[0035] Optionally, the application identity credential information may include at least one of the target application's application identifier and signature feature information.

[0036] The application identifier can be information used to identify the target application, such as the target application's identity number (id) or application package name. The signature feature information can be the certificate fingerprint of the target application's signature. This certificate fingerprint can be a feature value calculated using a hash algorithm (e.g., SHA-256) on the public key certificate used to sign the target application. This signature feature information can be called a signature feature value or a signature fingerprint.

[0037] In one embodiment, the mapping relationship can be stored in a credit mapping database (also known as a virtual signature credit table). The mapping relationship for each application can include information such as the application package name, signature feature value (i.e., certificate fingerprint), authorized API list, compliance review status (passed), and mapping effective time (current timestamp).

[0038] There are several ways to perform permission verification processing on the first interface call request based on the target application programming interface. For example, if the target application programming interface includes the first application programming interface, the permission verification processing result of the first interface call request can be determined to be passed; and / or, if the target application programming interface does not include the first application programming interface, the permission verification processing result of the first interface call request can be determined to be failed.

[0039] When the target application programming interface includes a first application programming interface, it can be indicated that the first application programming interface is an application programming interface that the target application has the right to call. Thus, the target application can be allowed to call the first application programming interface through the permission verification process of the first interface call request.

[0040] When the target application programming interface does not include the first application programming interface, it can be indicated that the first application programming interface is not an application programming interface that the target application has the right to call. Therefore, it can be determined that the permission verification result of the first interface call request is unsuccessful, and the target application is refused to call the first application programming interface.

[0041] Optionally, there are several other ways to perform permission verification processing on the first interface call request based on the target application programming interface. For example, when the target application programming interface includes the first interface call request, the permission verification processing result of the first interface call request can be determined to be unsuccessful if the first application programming interface is a high-risk interface and the vehicle to which the vehicle terminal belongs is in motion; and / or, the permission verification processing result of the first interface call request can be determined to be successful if the first application programming interface is a high-risk interface and the vehicle to which the vehicle terminal belongs is not in motion.

[0042] The high-risk interface can be an application programming interface (API) that poses a high security risk when called, such as APIs related to vehicle control or sensitive data reading. APIs classified as high-risk can be pre-defined based on actual needs.

[0043] In one embodiment, this application can collect information such as the vehicle's operating status (stationary / moving), speed, and gear position. If the vehicle is in motion, calling high-risk API interfaces is prohibited; if the vehicle is stationary, and after successful permission verification based on the mapping relationship, the application can be allowed to call the high-risk API. Thus, by performing secondary verification on high-risk API interfaces, the security of application permission calls can be further improved.

[0044] Optionally, if the permission verification process passes, the application identifier of the target application and the interface identifier of the first application programming interface can be written into the preset cache information; based on the preset cache information, if a second interface call request initiated by the target application for the first application programming interface is subsequently received, the permission verification process result of the second interface call request is determined to be passed.

[0045] The preset cache information can be a record of interface call information that has passed permission verification, and may include the identifier of the application and application programming interface corresponding to the interface call request that has passed permission verification. The second interface call request can be a request subsequently initiated by the target application to call the first application programming interface.

[0046] Optionally, preset failure conditions can be set in the preset cache information. When the preset cache information meets the preset failure conditions, the second interface call request is processed for permission verification based on the mapping relationship. The preset failure conditions include at least one of the following: the permissions of the target application change, the status of the vehicle where the vehicle terminal is located changes, and the target application is restarted.

[0047] In one embodiment, if the permission verification result of the first interface call request passes, a signal indicating permission permission can be returned to the vehicle system's native PackageManager module, enabling the application to execute the API call for the first application programming interface. Simultaneously, the permission verification result is written to a preset cache based on the target application's process and the interface identifier of the first application programming interface. Subsequent repeated calls to the same API by the target application can directly read the cached permission verification result, skipping the complete intermediate judgment process, ensuring smooth operation in high-frequency call scenarios, and the process terminates. If the permission verification result of the first interface call request fails (mapping relationship comparison failure or secondary verification failure), the permission denied state can be maintained, and an interface call permission denied signal can be returned to the application, prohibiting the target application from calling the first application programming interface, and the process terminates.

[0048] Optionally, the preset cached information will become invalid immediately under the following circumstances, and the full verification process will be retried on the next call: when the cloud pushes a permission change or revocation command for the application, the preset cached information of the corresponding application will be cleared; when the vehicle status changes (such as switching from stationary to moving), the cached results involving high-risk APIs will be cleared immediately; when the application process restarts, all preset cached information corresponding to that application will automatically become invalid. In this way, these cache invalidation mechanisms can ensure that the dynamic revocation of application permissions takes effect in real time, and that revoked permissions are not continuously used due to caching.

[0049] In one embodiment, the vehicle terminal can synchronize bidirectionally with the cloud. When the cloud updates or cancels the mapping relationship, the changed information can be quickly pushed to the vehicle terminal through the communication connection between the vehicle terminal and the cloud, so as to realize the real-time synchronization of the mapping relationship and provide support for dynamic adjustment of permissions and second-level revocation.

[0050] For example, upon receiving a permission revocation instruction for a target application from the cloud, the target mapping relationship corresponding to the target application is marked as invalid; upon receiving a third interface call request initiated by the target application for the second application programming interface, the permission verification result of the third interface call request is determined to be unsuccessful based on the marked target mapping relationship.

[0051] Specifically, the permission revocation instruction can be an instruction to revoke the target application's interface call permissions. The target mapping relationship can be a mapping relationship corresponding to the target application. The second application programming interface can be the application programming interface requested by the target application after permission revocation. The third interface call request can be the interface call request initiated by the target application after permission revocation.

[0052] Thus, the application permission management method provided in this application, by introducing a virtual signature authorization table, realizes the mapping and authorization of the native signature feature value of third-party applications to API permissions. This eliminates the need for physical resigning of the application, allowing it to maintain its native signature in the app store and keeping the application package hash value unchanged. Simultaneously, it authorizes specific APIs for individual applications, achieving fine-grained permission control, avoiding over-authorization, and reducing security risks. After a third-party application is updated, since its native signature feature value remains unchanged, there is no need to re-authorize; only the signature feature value needs to be verified to continue using the authorized permissions, significantly reducing OEM management costs and third-party application update costs.

[0053] Furthermore, in this embodiment, the virtual signature trust table only stores the application's signature feature value, application package name, and authorized API list, eliminating the need for pre-configured public keys and avoiding the complexity of public key management while completely avoiding the risk of private key leakage. In addition, this embodiment constructs a full-process dynamic authorization mechanism that can adjust permissions in real time based on the application's compliance review status and vehicle status, achieving dynamic authorization. When an application has security vulnerabilities or violates regulations, the application's mapping relationship can be remotely revoked via the cloud, achieving second-level revocation of API permissions without uninstalling the application, thus improving the efficiency and flexibility of application permission management.

[0054] As described above, this embodiment of the application determines the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface; based on the mapping relationship, it performs permission verification processing on the first interface call request. The mapping relationship includes the correspondence between the application and at least one application programming interface that it can call. Therefore, by determining the application programming interface that the target application has the permission to call based on the preset mapping relationship, and thus performing permission verification processing on the first interface call request based on the mapping relationship, the compatibility between the application and the vehicle system is improved. This avoids the situation where the hash value of the application package is changed during the application and application programming interface authorization process, which would prevent subsequent incremental updates of the application from proceeding normally, thereby improving the efficiency of permission management for vehicle applications.

[0055] To better implement the above methods, this application embodiment also provides another application permission management method. This configuration upgrade method can be integrated into a computer device, which can be a server.

[0056] For a better description of the embodiments of this application, please refer to Figure 3 , Figure 3 Another flowchart illustrating the configuration upgrade method provided in this application embodiment. This application permission management method is applied in the cloud and includes: Step 201: Based on the correspondence between the applications running on the vehicle terminal and at least one application programming interface that can be called, generate the mapping relationship corresponding to each application.

[0057] This application can be one that passes cloud-based compliance audits and automated testing.

[0058] There are several ways to generate the mapping relationship for each application based on the correspondence between the application running on the vehicle terminal and at least one application programming interface that it can call. For example, the mapping relationship for each application can be generated based on the application installation package of the application running on the vehicle terminal and at least one application programming interface that the application can call.

[0059] The application installation package can be an application installation package, which may include third-party application installation packages developed by developers or third-party application installation packages that can be directly downloaded from the application market by the vehicle.

[0060] There are several ways to identify at least one application programming interface that an application can call based on the application installation package of the application running on the vehicle terminal. For example, at least one application programming interface that an application can call can be determined based on a first candidate application programming interface and a second candidate application programming interface. The first candidate application programming interface is obtained by performing static code analysis on the application installation package of the application, and the second candidate application programming interface is obtained by running the application based on the application installation package.

[0061] The first candidate application programming interface (API) can be the API that the application needs to call, determined by static code analysis of the application's installation package. The second candidate API can be the API that the application needs to call, determined by running the application based on the application's installation package.

[0062] In one specific embodiment, static code analysis can be performed on the application installation package to obtain a first candidate application programming interface that the application needs to call; the application can be run based on the application installation package to identify a second candidate application programming interface that the application needs to call; based on the first candidate application programming interface and the second candidate application programming interface, at least one application programming interface that the application can call can be determined.

[0063] The first candidate application programming interface (API) can be the API required by the application, obtained through analysis of the code in the application installation package. The second candidate API can be the API required by the application, identified by running the application installation package.

[0064] For example, the application installation package can be decompiled to scan all AutoAPI call points in the application's code, generating an API call intent list for the application. This list includes APIs declared to be called in the application code (i.e., the first candidate application programming interfaces). Furthermore, dynamic sandbox testing can be used to actually run the application in an isolated sandbox, monitoring runtime API calls through instrumentation to obtain the second candidate application programming interfaces. Next, the second candidate application programming interfaces can be cross-compared with the first candidate, filtering out redundant APIs in the first candidate that are not actually called. This allows for the identification of additional calls hidden through reflection and dynamic loading, preventing malicious applications from bypassing static analysis. Finally, manual approval (by OEM reviewers) can be conducted based on the first and second candidate application programming interfaces, according to application type, functional positioning, and the principle of least privilege. APIs that clearly exceed functional requirements are rejected, ensuring that each application only receives the minimum permissions necessary for normal operation. This ultimately determines the application's authorized API list (i.e., at least one application programming interface that the application can call).

[0065] Optionally, after the application passes the compliance audit test, this embodiment of the application does not require physical signing of the application. It only needs to extract the application's native signature feature value (e.g., a certificate fingerprint generated based on the SHA-256 algorithm) and the application's package name, ensuring that the extracted feature values ​​are unique and tamper-proof. The SHA-256 encryption algorithm has high security and can effectively prevent the signature feature value from being forged, ensuring the uniqueness of the application's identity. After the application's authorized API list is determined, the application package name, application certificate fingerprint, authorized API list, compliance audit status (passed), and mapping effective time (current timestamp) can be associated to form a complete mapping relationship for the application.

[0066] Step 202: Send the mapping relationship to the vehicle terminal.

[0067] There are several ways to send the mapping relationship to the vehicle terminal. For example, a Transport Layer Security (TLS) encrypted transmission protocol can be used, combined with vehicle device authentication (verifying the vehicle device serial number and hardware encryption chip information), to push the mapping relationship to the encrypted partition of the vehicle system corresponding to the vehicle terminal and write it into the trusted mapping database. In this way, the vehicle terminal can obtain the mapping relationship through the trusted mapping database.

[0068] To facilitate better implementation of the application permission management method provided in this application embodiment, this application embodiment also provides an application permission management system. The meanings of the terms used are the same as in the application permission management method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0069] The application permission management system provided in this application embodiment may include an in-vehicle terminal and a cloud. The cloud can generate a mapping relationship for each application based on the correspondence between the applications running on the in-vehicle terminal and at least one application programming interface (API) that the application can call, and send the mapping relationship to the in-vehicle terminal. The in-vehicle terminal determines a first API call request initiated by a target application running on the in-vehicle terminal for a first API, and performs permission verification processing on the first API call request based on the mapping relationship.

[0070] In one embodiment, please refer to Figure 4a , Figure 4a This is an overall system architecture diagram of an application permission management method provided in this application embodiment. The application permission management system provided in this application embodiment can dynamically authorize vehicle-mounted API permissions based on virtual signature mapping. The application permission management system can include two main parts: a vehicle-side system and an OEM cloud management platform (hereinafter referred to as the cloud). The vehicle-side system includes: an application running module, a vehicle-mounted native PackageManager module, an enhanced version of the Permission Management Service (PMS), a security authentication relay module, and a trust mapping database, etc.; the OEM cloud management platform can include: a compliance review module, a signature feature extraction module, a cloud mapping management module, an encrypted transmission module, etc.

[0071] Specifically, the compliance audit module of the OEM cloud management platform is connected to the signature feature extraction module, the signature feature extraction module is connected to the cloud mapping management module, and the cloud mapping management module is connected to the encrypted transmission module; the encrypted transmission module is connected to the credit mapping database of the vehicle system; the application operation module of the vehicle system is connected to the vehicle's native PackageManager module, the vehicle's native PackageManager module is connected to the enhanced version of the Permission Management Service (PMS), the enhanced version of the Permission Management Service (PMS) is connected to the security authentication relay module, and the security authentication relay module is connected to the credit mapping database.

[0072] Thus, the application permission management system provided in this application embodiment can solve the technical defects of the prior art, such as the need for OEM re-signing of third-party applications, high risk of private key leakage, inability to dynamically control permissions, and high application update costs. This enables secure, efficient, and flexible authorization of vehicle system API permissions, while maintaining a clean application ecosystem and reducing management costs.

[0073] Among them, the OEM cloud management platform can serve as the core for third-party application compliance audit testing, signature feature extraction, and mapping relationship management. Deployed on the OEM's cloud server, it can employ high-security encryption protection to prevent data from being tampered with or stolen.

[0074] The compliance review module receives application installation packages from third-party applications submitted by the vehicle-cloud synchronization upload module, and performs comprehensive compliance reviews and automated testing on these applications. Review content includes application security, compatibility, and privacy compliance, ensuring the application meets the security requirements of the vehicle infotainment system and relevant industry standards. Automated testing is divided into two levels: First, static code analysis, which decompiles the application installation package, scans all AutoAPI call points in the code, and generates an application API call intent list as the basis for determining the subsequent authorized API list; second, dynamic sandbox testing, which runs the application in an isolated sandbox environment, monitors the actual API call behavior initiated during runtime through instrumentation, cross-compares the results with the static analysis, identifies hidden calls (such as API calls initiated through reflection or dynamic loading) or API calls exceeding the declared limits, preventing malicious applications from bypassing static analysis to obtain unauthorized access; simultaneously, stability testing, security vulnerability scanning, and permission call rationality testing are combined to ensure the application meets the security requirements of the vehicle infotainment system. If the test passes, the application is marked as "passed" and an API call intent list is output; otherwise, it is marked as "compliance failed" and its access is rejected. The core function of this module is to screen legitimate and safe third-party applications, while providing a data foundation for the accurate determination of the authorized API list, thereby avoiding security risks from the source and preventing malicious applications from accessing the vehicle's infotainment system.

[0075] The signature feature extraction module is connected to the compliance review module. After a third-party application passes the compliance review, this module does not need to physically sign the application. It only extracts the signature feature value of the application's native signature and the application package name to ensure that the extracted feature value is unique and cannot be tampered with.

[0076] The cloud-based mapping management module connects with the signature feature extraction module to generate a mapping relationship between applications and authorized API lists. The determination of the authorized API list employs a three-tiered mechanism: static analysis, dynamic testing, and manual approval. The first tier uses the static API call intent list output by the compliance review module to obtain all APIs declared for application calls, serving as candidate authorizations. The second tier combines dynamic sandbox testing results to filter redundant APIs not actually called from the static list, while also including additional calls discovered during dynamic testing to prevent unauthorized authorization. The third tier involves OEM reviewers manually approving the API candidate lists from the first two tiers based on application type, functional positioning, and the principle of least privilege. API call requests that clearly exceed application functional requirements are rejected, ultimately determining the authorized API list and ensuring that each application only receives the minimum permissions necessary for normal operation. Once the authorized API list is determined, the application package name, application certificate fingerprint, authorized API list, compliance review status (passed), and mapping effective time can be linked to form a complete mapping relationship. Meanwhile, this module supports updating, querying, and deleting mapping relationships. It can dynamically adjust the authorized API list based on changes in the application's compliance audit status and function updates, ensuring the flexibility of permission control. All write and modification operations of mapping relationships are recorded in operation logs (including operator, operation time, and changes) for subsequent security audits to prevent internal personnel from maliciously tampering with authorization configurations.

[0077] The encrypted transmission module connects to the cloud-based mapping management module and also to the vehicle-side system's trusted mapping database. It can be used to push cloud-generated mapping relationships to the encrypted partition of the vehicle's infotainment system in an encrypted manner. Employing the TLS encrypted transmission protocol, combined with the vehicle's device authentication, it ensures that mapping relationships are not stolen or tampered with during transmission. Simultaneously, this module supports bidirectional synchronization between the cloud and the vehicle. When the cloud updates or cancels mapping relationships, this module can quickly push the updates to the vehicle, achieving real-time synchronization and supporting dynamic permission adjustments and second-level revocation.

[0078] Optionally, the vehicle-side system can be deployed on in-vehicle terminals (such as in-vehicle infotainment systems). It serves as the core for dynamic API permission authorization, communicating bidirectionally with the OEM's cloud-based management platform and interacting with third-party applications. Specifically, it includes the following five core modules, which work together to achieve end-to-end control from API call interception to permission determination: The trust mapping database (i.e., the virtual signature trust table) is an encrypted database stored in an encrypted partition of the vehicle's infotainment system. Access is restricted to the security authentication relay module and the enhanced version of the Permission Management Service (PMS). The stored data is encrypted using the SHA-256 encryption algorithm to prevent tampering or theft. Its core function is to store the mapping relationship between applications and API permissions, providing data support for relay determination.

[0079] The Enhanced Permission Management Service (PMS) is the core of the vehicle infotainment system's permission verification. It enhances the native Android Permission Manager Service by embedding intermediary judgment logic within the native permission verification logic, without modifying the core code of the native verification logic, thus ensuring compatibility with the vehicle infotainment system. Its core functions include: receiving permission verification requests from the vehicle's native PackageManager module, calling the security authentication intermediary module for intermediary judgment, receiving the intermediary judgment result, and returning the permission verification result (allow or deny the call) to the PackageManager module based on the result. Simultaneously, this module has a built-in permission verification result caching mechanism, caching the judgment result of the complete verification process according to the application process and API identifier. Subsequent repeated calls by the same application to the same API directly read the cached result, eliminating the need to repeatedly trigger the complete intermediary judgment process, significantly reducing system performance overhead in high-frequency call scenarios (such as navigation applications reading vehicle speed in real time and dashboard applications continuously refreshing vehicle status data). The preset expiration conditions for the cache can include: cloud-push notifications of permission changes or revocation commands, changes in vehicle status (affecting the secondary verification results of high-risk APIs), and application process restart. When any of these conditions are triggered, the cache is immediately cleared, and the entire verification process is re-executed on the next call, ensuring that the caching mechanism does not affect the real-time performance of dynamic permission revocation. Simultaneously, this module supports the recording of permission verification logs for subsequent security audits and troubleshooting, meeting security audit requirements. This enhanced design retains the permission verification logic of the native system while achieving a balance between dynamic authorization and performance optimization for high-frequency calls, reducing development and adaptation costs.

[0080] The security authentication relay module includes a permission denial signal interception submodule, an identity tracing submodule, a mapping comparison submodule, a permission spoofing / elevation submodule, and a secondary verification submodule. These submodules work together to achieve identity equivalence for third-party applications and dynamic permission determination.

[0081] The permission denial signal interception submodule connects to the enhanced version of the Permission Management Service (PMS) to intercept permission denial signals returned by the vehicle's native PackageManager module. When a third-party application initiates an API call, the native PackageManager module performs a permission pre-check. If it finds that the application has not been physically signed by the OEM and cannot pass the signature verification, it will return a Permission Denied signal. This submodule intercepts this signal in real time to prevent the application from being directly denied API calls, providing a time window for subsequent transit judgment.

[0082] The identity tracing submodule is connected to the permission denial signal interception submodule. It is used to obtain the unique identifier (User ID, or UID) of the API caller and then uses the vehicle system's native interface to look up the application package name and the SHA-256 hash of the application's native signature corresponding to that UID. This submodule employs a secure tracing algorithm to ensure that the obtained application package name and signature hash are authentic and tamper-proof, preventing identity forgery. By reading the signature certificate file in the application's installation directory, it extracts the certificate fingerprint and compares it with the application information cached by the system to confirm the caller's true identity, providing accurate identity evidence for subsequent mapping comparisons.

[0083] The mapping comparison submodule is bidirectionally connected to the identity tracing submodule and the trust mapping database. Its core function is to accurately compare the application package name and signature feature value obtained by the identity tracing submodule with the mapping relationships stored in the trust mapping database. The comparison process employs a dual matching logic: first, it matches the application package name to confirm the existence of a relevant record for the application in the database; second, it matches the signature feature value to ensure that the caller's identity matches the trusted application's identity; simultaneously, it checks the application's compliance review status in the database. The comparison is considered successful only if both the package name and signature feature value match and the compliance status is "passed"; otherwise, the comparison is considered a failure. The entire comparison process is encrypted to prevent data tampering and ensure the accuracy of the judgment results.

[0084] The Permission Impersonation / Elevation Submodule connects to the Mapping Comparison Submodule. When the Mapping Comparison Submodule determines a successful comparison, this submodule generates an "Equivalent Signature Passed" signal, simulating the result of the vehicle's native signature verification passing. This achieves the equivalence of the third-party application's identity and permission impersonation / elevation. Specifically, this submodule returns a simulated "Signature Verification Passed" signal to the Enhanced Permission Management Service (PMS), along with the application's authorized API list. This informs the Enhanced PMS that the application has the permission to call the corresponding APIs, allowing the system to recognize the legitimacy of the third-party application's native signature. This allows the application to obtain the corresponding permissions without a physical signature, resolving the core issue of incompatibility between native permission verification and the third-party application's native signature.

[0085] The secondary verification submodule connects to the permission spoofing / elevation submodule and the vehicle status collection module of the vehicle-side system. Its core function is to perform secondary verification on high-risk APIs, further enhancing the security of permission calls. The core of secondary verification is vehicle status verification. By collecting information such as the vehicle's driving status (stationary / moving), speed, and gear position, calls to high-risk APIs are prohibited if the vehicle is moving; only calls to high-risk APIs are allowed if the vehicle is stationary and the mapping comparison passes. Simultaneously, this submodule supports configurable secondary verification rules. OEMs can add verification items (such as user authentication and vehicle location verification) according to actual needs, improving the flexibility and security of permission control.

[0086] The in-vehicle infotainment system's native PackageManager module is a native module provided by the Android automotive operating system. Its core code has not been modified; its core function is to perform permission pre-checks for API calls. When a third-party application initiates an API call, this module first checks whether the application has an OEM physical signature and whether it possesses native permissions. If the physical signature verification fails, a Permission Denied signal is returned, which is intercepted by the security authentication relay module. If the physical signature verification passes, a permission allowed signal is returned directly, ensuring the normal use of native OEM-signed applications and achieving compatibility with the native system. The core purpose of retaining this module is to maintain the in-vehicle infotainment system's native permission verification logic and avoid system stability issues caused by technical modifications.

[0087] The application runtime module serves as the platform for third-party applications to run on the in-vehicle infotainment system. It receives API call requests from these applications, forwards them to the system's native PackageManager module, receives permission verification results, and executes or terminates the API call. This module works in conjunction with other modules of the in-vehicle infotainment system to ensure that applications can call APIs correctly after obtaining authorization, and to promptly terminate API calls when permissions are denied or revoked, preventing unauthorized access.

[0088] In one specific embodiment, please refer to Figure 4b , Figure 4bThis is a schematic diagram of the trust mapping database structure of an application permission management method provided in this application embodiment. The trust mapping database can be an encrypted database, stored in an encrypted partition of the vehicle system, accessible only to the security authentication relay module and the enhanced version of the permission management service (PMS). Furthermore, the data can be encrypted using the SHA-256 encryption algorithm to prevent data tampering. The trust mapping database can store multiple mapping relationships. It can primarily include five core fields: application package name, application certificate fingerprint, compliance review status (passed / failed / revoked), mapping effective time, and authorized API list (which can store multiple API identifiers and supports fine-grained configuration).

[0089] The application package name and application certificate fingerprint form a composite primary key, uniquely identifying a third-party application. The compliance review status and mapping effective time are associated with the composite primary key to control the validity of the mapping relationship. The authorized API list is associated with the application package name and certificate fingerprint; one application can correspond to multiple authorized APIs.

[0090] In one specific embodiment, please refer to Figure 4c , Figure 4c This is a schematic diagram of the security authentication relay module structure of an application permission management method provided in this application embodiment. The security authentication relay module may include core sub-modules such as a permission denial signal interception sub-module, an identity tracing sub-module, a mapping comparison sub-module, a permission spoofing / elevation sub-module, and a secondary verification sub-module.

[0091] The system includes several submodules: Permission Denied Signal Interception Submodule (connected to the Enhanced Permission Management Service (PMS) to intercept Permission Denied signals); Identity Tracing Submodule (connected to the Identity Tracing Submodule to obtain the caller's user identifier and retrieve the application package name and signature fingerprint); Mapping Comparison Submodule (connected to the Trust Mapping Database to query the mapping relationship corresponding to the application); Permission Impersonation / Elevation Submodule (connected to the Permission Impersonation / Elevation Submodule to generate an "Equivalent Signature Passed" signal upon successful matching); Secondary Verification Submodule (connected to the Secondary Verification Submodule to verify vehicle status (e.g., stationary / moving) and perform secondary verification for high-risk APIs); and Secondary Verification Submodule (connected to the Enhanced Permission Management Service (PMS) to return the final permission verification result).

[0092] In one specific embodiment, please refer to Figure 4d , Figure 4dThis is a schematic diagram illustrating a specific process of an application permission management method provided in an embodiment of this application. The process may include an offline phase (compliant asset registration) and an operational phase (API call interception and relay determination), comprising seven core steps: Step 1: Submit third-party applications to the cloud via the vehicle-cloud synchronization upload module for compliance review and automated testing; Step 2: After compliance review is passed, extract the SHA-256 signature of the application's native signature and the application package name; Step 3: Generate the mapping relationship between the application and the authorized API, push it to the vehicle's encrypted partition via encrypted transmission, and write it to the trust mapping database; Step 4: The third-party application runs on the vehicle's infotainment system and initiates a Binder call to the AutoAPI; Step 5: The vehicle's native PackageManager module performs a permission pre-check. If successful, API calls are allowed directly, and the application's interface call request process ends. If unsuccessful, a Permission Denied signal is returned.

[0093] Step 6: The security authentication relay module intercepts the Permission Denied signal, completes identity tracing, mapping relationship comparison, and secondary verification (if necessary). If the mapping comparison fails (no match in the database or compliance status is failed / revoked), no equivalent signature pass signal is generated, and the Permission Denied signal is maintained. If the mapping comparison succeeds, it determines whether the API currently requested is a high-risk API. If not, an equivalent signature pass signal is generated; if so, secondary verification (vehicle status verification) can be performed, and the application is only allowed to call the API when the vehicle is stationary.

[0094] Step 7: The Permission Management Service (PMS) Enhanced Module receives the permission verification result, allows the application to call the API or denies the call, and the application's interface call process ends.

[0095] Specifically, in step 1, when a third-party application is submitted for compliance review, the application installation package can be submitted to the OEM cloud management platform through the vehicle-cloud synchronous upload module. After receiving the application installation package, the cloud compliance review module will initiate a comprehensive compliance review and automated testing.

[0096] When performing signature feature extraction in step 2, the signature feature extraction module can obtain the application installation package of the approved third-party application without performing any physical signature operation on the application. It only extracts the SHA-256 feature value of the application's native signature and the application package name through the encryption parsing tool.

[0097] In step 3, the cloud mapping management module determines the authorized API list through a three-tiered mechanism of static analysis, dynamic testing, and manual approval: First, based on the static API call intent list output in the compliance review phase of step 1, all APIs declared for application calls are obtained as candidate APIs; second, the candidate APIs are revised based on the results of dynamic sandbox testing, filtering redundant APIs and including additional calls discovered during dynamic testing for review; finally, OEM reviewers manually approve the candidate list based on application type, functional positioning, and the principle of least privilege, ultimately determining the authorized API list. Simultaneously, fine-grained configuration is supported; for example, navigation applications may only authorize APIs related to map data reading and positioning, while entertainment applications may only authorize APIs related to audio playback and screen display, avoiding over-authorization.

[0098] During the runtime phase, API call interception and relay determination are performed. Third-party applications run normally on the in-vehicle infotainment system. When they need to call the AutoAPI, they initiate interface call requests across processes via the Android system's Binder mechanism. The AutoAPI is a custom-encapsulated interface for in-vehicle systems by the OEM based on the Android automotive operating system. It provides system-level interfaces related to core vehicle functions, such as vehicle status reading (speed, gear, fuel level, etc.), vehicle control (air conditioning, windows, seats, etc.), navigation data interaction, and audio and screen control. In the actual operation of in-vehicle applications, third-party applications will initiate Binder calls multiple times, even continuously and frequently. For example, navigation applications need to obtain vehicle speed and location information in real time (multiple times per second), dashboard applications need to continuously refresh vehicle status data such as RPM and fuel level, and entertainment applications trigger calls every time the user performs an action (changing songs, adjusting volume, etc.). Therefore, each Binder call triggers a complete permission verification process (steps 5 to 7). The lightweight design of the security authentication relay module (average verification latency of 15ms) ensures that the smooth operation of applications is not affected in high-frequency call scenarios. The aforementioned Binder call request is forwarded by the application runtime module to the vehicle's native PackageManager module, where it enters the permission pre-check stage.

[0099] After receiving the API call request, the vehicle's native PackageManager module performs a permission pre-check on the application, primarily checking whether the application has an OEM physical signature and whether it possesses native permissions. If the application has an OEM physical signature and the corresponding native permissions, it directly returns a permission-allowed signal, the application execution module executes the API call, and the process ends. If the application has not been physically signed by the OEM and fails the signature verification, it returns a Permission Denied signal. This signal is intercepted in real time by the permission denial signal interception submodule of the security authentication relay module, and enters the relay judgment stage.

[0100] In the transit judgment process of step 6, the security authentication transit module initiates the transit judgment process, with each sub-module working collaboratively. Specifically, the identity tracing sub-module obtains the API caller's UID and uses the vehicle's native interface to look up the application package name and the SHA-256 signature of the application's native signature corresponding to that UID, ensuring that the obtained identity information is authentic and tamper-proof, thus completing the caller's identity verification. The mapping comparison sub-module performs a double match between the application package name and signature signature obtained from identity tracing and the mapping relationship in the trust mapping database, while simultaneously verifying the application's compliance review status. If both the package name and signature signature match, and the compliance review status is "passed," the comparison is deemed successful; if the package name does not match, the signature signature does not match, or the compliance review status is "failed" or "revoked," the comparison is deemed unsuccessful, no equivalent signature pass signal is generated, and the process proceeds to the call rejection stage in step 7.

[0101] In one specific embodiment, please refer to Figure 4e , Figure 4e This is an interactive schematic diagram of an application permission management method provided in an embodiment of this application. In the interaction between the cloud and the vehicle, the OEM cloud management platform may include: a mapping relationship management submodule, a compliance status update submodule, and a permission revocation submodule; the vehicle system may include: a trust mapping database, a vehicle synchronization submodule, and a permission activation submodule.

[0102] The mapping relationship management submodule can generate or update application mapping relationships, and then transmit them to the vehicle-side synchronization submodule via encryption. The vehicle-side synchronization submodule writes the data to the trust mapping database. The cloud-based compliance status update submodule can update the application's compliance review status, and then push it to the vehicle-side synchronization submodule via encryption. The vehicle-side synchronization submodule updates the compliance review status in the database. The cloud-based permission revocation submodule can send permission revocation commands (such as canceling mapping relationships), and then push them to the vehicle-side synchronization submodule via encryption. The vehicle-side synchronization submodule marks the mapping relationships in the database as canceled, and immediately prohibits API calls of the relevant applications through the permission activation submodule, achieving permission revocation within seconds.

[0103] Optionally, in addition to extracting the SHA-256 signature of the application's native signature, the signature feature extraction module can add a validity period check of the application signing certificate. If the application signing certificate has expired, it will be directly determined as failing the compliance review and the mapping relationship will be refused. At the same time, a dual encryption extraction method can be adopted. First, the application installation package is encrypted and parsed based on the Advanced Encryption Standard (AES) and then the signature feature value is extracted to further prevent the feature value from being tampered with and improve the accuracy of identity recognition.

[0104] Optionally, the credit mapping database can adopt a dual storage mode of local encrypted storage + cloud backup. The local storage uses the SHA-256 encryption algorithm, and the cloud backup uses the AES-256 encryption algorithm to ensure that the mapping relationship is securely stored both locally and in the cloud. At the same time, the database supports a periodic synchronization mechanism. The vehicle system synchronizes the mapping relationship with the OEM cloud management platform once an hour to ensure that the updated mapping relationship in the cloud (such as permission adjustment and cancellation) can be synchronized to the vehicle in a timely manner, improving the real-time performance of management.

[0105] Optionally, the secondary verification submodule can add a user authentication function. For high-risk API calls, in addition to verifying the vehicle status, it is also necessary to verify the identity of the currently logged-in user (such as through vehicle account password, biometrics, etc.). High-risk API calls are only allowed when the user authentication is successful and the vehicle status meets the requirements. At the same time, dynamic configuration of secondary verification rules is supported. OEMs can adjust the triggering conditions of secondary verification (such as the verification requirements of different types of high-risk APIs) through the cloud management platform to improve the flexibility of permission management.

[0106] The cloud-based permission revocation submodule supports both batch revocation and single revocation modes. It can revoke the mapping relationship of a single violating application or revoke the mapping relationship of a certain type of violating applications (such as applications with security vulnerabilities) in batches. At the same time, after permission is revoked, the vehicle-side synchronization submodule immediately marks the mapping relationship of the application as "revoked" and notifies the PMS enhanced version to prohibit all API calls of the application, achieving revocation in seconds without restarting the application or vehicle system, thus improving management efficiency.

[0107] In current in-vehicle infotainment system API permission authorization scenarios, the industry-standard technology still relies on physical signature verification as its core. Physical signature refers to the actual writing of signature data into the application installation package file. This is done by encrypting the installation package content with a private key and embedding the signature information into the installation package file itself, which alters the binary content and hash value of the application installation package. Physical signature verification involves the OEM generating a signature for the application installation package file using its private key, and the in-vehicle infotainment system verifying the signature's validity using a pre-set public key. The entire process relies on a cryptographic mechanism of "private key signing + public key verification," and the content of the installation package file itself has been altered. Whether it's the traditional OEM re-signing mode or the dual-signature verification mode, both essentially remain within the inherent logic of signature-bound permissions, exhibiting the following technical shortcomings: First, the industry's technical logic is rigid, overly relying on the identity authentication function of physical signatures: In-vehicle infotainment systems are high-security devices, and the industry generally believes that physical signatures are the only reliable way to confirm the legitimacy of applications. Therefore, all third-party applications must pass the OEM's physical signature to be recognized by the system and granted API permissions. This rigid technical logic ignores the management costs and compatibility issues brought about by physical signatures, and also fails to consider the value of native signatures for third-party applications. This results in low efficiency for application integration and updates, making it unable to adapt to the rapidly evolving in-vehicle infotainment application ecosystem.

[0108] Secondly, the key management system is imperfect, and there are security vulnerabilities in the storage and use of private keys: Currently, the key management system in the automotive industry generally suffers from the problem of centralized storage and batch use of private keys. In order to achieve batch signing of applications, OEMs' signing private keys must be deployed on automated production lines. However, the network environment of the production line is complex and personnel turnover is frequent, which makes it easy for private keys to be leaked. At the same time, there is a lack of unified key security management standards in the industry. Most car companies' key management only meets the basic requirements of encrypted storage and has not established a sound mechanism for hierarchical management, usage auditing and emergency response of private keys, which further exacerbates the risk of private key leakage.

[0109] Furthermore, the access control system is inadequate, lacking dynamic and fine-grained control capabilities: Currently, most in-vehicle system access control in the industry uses a one-time authorization model, meaning that permissions are assigned during application installation and no further verification or adjustment is performed during operation. This model cannot adapt to the dynamic changes of in-vehicle applications. Third-party applications may undergo version updates or changes in compliance status, and vehicles may be in different driving states (stationary, moving). Static authorization cannot adjust permissions based on these dynamic factors. At the same time, most access control systems in the industry can only achieve application-level permission allocation, failing to achieve fine-grained control at the API level, which can easily lead to over-authorization and increase security risks.

[0110] Furthermore, the security verification process is incomplete and does not cover the entire application lifecycle: most technical solutions in the industry only focus on security verification during the application installation stage, ignoring API call verification during the application runtime stage, resulting in a control loophole of "strict during installation, lenient during runtime"; at the same time, secondary verification is not performed in conjunction with vehicle driving scenarios, which does not meet the control requirements for high-risk commands. For example, some existing technologies do not restrict the call of high-risk APIs while driving, which may interfere with the driver's operation and cause safety accidents. This is also a common security shortcoming in the current vehicle access control industry.

[0111] To address this, this application's embodiment introduces a virtual signature trust table to achieve mapping and trust between the native signature feature value of a third-party application and API permissions, eliminating the need for physical re-signing of the application. In existing technologies, physical signing of the third-party application (application signature + permission signature) is required, relying on key pairs for verification. This process prevents the application from maintaining its native signature, and the application package hash changes. However, this application's embodiment eliminates the need for any physical signing operation. It only extracts the SHA-256 feature value of the application's native signature and the application package name, generates a mapping relationship, and stores it in the virtual signature trust table (i.e., the trust mapping database). The application can maintain its native signature in the app store, and the application package hash remains unchanged.

[0112] Meanwhile, in existing technologies, the signing operation needs to be completed by the OEM, and third-party applications need to be resubmitted to the OEM for signing every time they are updated, resulting in high management costs. However, in the embodiments of this application, after the third-party application is updated, if the developer does not change the signing certificate, its original signature feature value remains unchanged. There is no need to re-perform the trust operation; only the signature feature value needs to be verified to continue using the authorized permissions, which significantly reduces the management costs of the OEM and the update costs of the third-party application.

[0113] Furthermore, existing trust authorization processes rely on pre-installed public keys, requiring the verification public key certificate to be pre-installed in the vehicle system, resulting in complex key management. In contrast, the virtual signature trust table in this application only stores application signature feature values, package names, and authorized API lists, eliminating the need for pre-installed public keys, thus avoiding the complexity of public key management and completely avoiding the risk of private key leakage.

[0114] Thus, through the embodiments of this application, the application ecosystem can be kept pure. Third-party applications can maintain their own native signatures without needing to adapt to the OEM's signature rules, facilitating simultaneous updates across multiple platforms such as in-vehicle systems and mobile devices. This also avoids compatibility issues caused by changes in the application package hash, improves application stability, and promotes the healthy development of the in-vehicle application ecosystem. OEMs do not need to physically sign every third-party application and its update; they only need to conduct compliance audits and extract signature feature values ​​to complete authorization, significantly reducing manpower and time costs. Third-party applications do not need to have the OEM re-sign each time they update, reducing application access and update costs and improving application update efficiency. OEMs do not need to deploy the highest-level signature private key on automated production lines; they only need to store the application signature feature value, completely avoiding the risk of private key leakage, preventing malicious applications from forging signatures to illegally obtain API permissions, and improving the security of the in-vehicle system.

[0115] Secondly, this application embodiment designs a security authentication relay module, which is embedded in the verification logic of the enhanced version of the Permission Management Service (PMS) to realize the identity equivalence of third-party applications and permission spoofing / elevation, intercept permission denial signals, and complete the relay judgment.

[0116] Existing technologies lack a relay judgment module, relying solely on the signature verification logic of the native PackageManager for permission verification. If an application has not undergone OEM physical signature verification, permission is directly denied, failing to achieve legitimate authorization for non-OEM signed applications. This application's embodiment, however, designs a secure authentication relay module embedded within the enhanced permission verification logic of the PMS. This module intercepts the native permission denial signal and, through identity tracing and mapping comparison, achieves the equivalence of the third-party application's identity, allowing the system to recognize the legitimacy of its native signature.

[0117] Furthermore, the permission verification logic of existing technologies is rigid, only able to determine whether to grant permissions based on the physical signature result, and cannot be dynamically adjusted. In contrast, the transit judgment logic of the embodiment of this application is flexible, and can dynamically adjust the permission verification result based on the compliance status and authorized API list in the trust mapping database. It also supports adding a secondary verification step to improve the security of high-risk API calls.

[0118] Next, existing technologies require modification of the native PackageManager verification logic in the vehicle infotainment system, resulting in high development costs and poor compatibility. In contrast, the embodiments of this application only embed the transfer determination logic within the enhanced PMS version, without modifying the core code of the native PackageManager. This provides strong compatibility and can be adapted to mainstream vehicle infotainment systems such as Android Automotive OS, reducing development and adaptation costs.

[0119] Thus, through the embodiments of this application, identity equivalence and permission spoofing / elevation can enable the vehicle system to recognize the native signature of third-party applications, obtaining corresponding API permissions without physical signatures. This solves the problem of incompatibility between the native signature of applications and system permission verification in the prior art, expanding the access scope of third-party applications. Without modifying the core code of the vehicle system's native system, dynamic permission authorization can be achieved solely through the optimization of the enhanced PMS and relay module, adapting to mainstream vehicle systems, reducing development cycle and adaptation costs, and facilitating large-scale application deployment. The relay judgment logic can dynamically adjust permissions based on application compliance status, vehicle status, etc., supporting secondary verification of high-risk APIs, meeting the control requirements of high-risk instructions, preventing high-risk APIs from being illegally called during driving, and improving the security of the vehicle system.

[0120] Furthermore, this application embodiment constructs a full-process dynamic authorization mechanism of "offline compliance registration - runtime interception - transit judgment," combined with cloud management to achieve second-level revocation of API permissions, supporting fine-grained permission control. Specifically, permission authorization in existing technologies only occurs during the application installation phase, which is static authorization, and permissions cannot be dynamically adjusted according to the application compliance status and vehicle status during operation. In contrast, this application embodiment constructs a full-process dynamic authorization mechanism, completing compliance asset registration offline and API call interception and transit judgment during the runtime phase, and can adjust permissions in real time according to the application compliance status and vehicle status, achieving dynamic authorization. Moreover, permission revocation in existing technologies requires uninstalling the application, which is cumbersome, slow, and cannot achieve remote management. In contrast, this application embodiment, combined with the OEM cloud management platform, can remotely revoke the application's mapping relationship through the cloud, achieving second-level revocation of API permissions without uninstalling the application, making management more efficient and flexible. Furthermore, existing technologies can only achieve application-level permission allocation and cannot achieve fine-grained control at the API level, which can easily lead to over-authorization. In contrast, the trust mapping database in this application stores the correspondence between applications and authorized API lists, which can authorize specific APIs for individual applications, achieve fine-grained permission control, avoid over-authorization, and reduce security risks.

[0121] Thus, through the embodiments of this application, dynamic permission control can be achieved. The full-process authorization mechanism can dynamically adjust permissions based on application compliance status, vehicle status, etc. When an application has security vulnerabilities or violates regulations, permissions can be adjusted or revoked in a timely manner, improving the security and flexibility of the vehicle system; improving permission control efficiency, remotely revoking permissions in seconds via the cloud without uninstalling the application, significantly reducing the management costs for OEMs, while also enabling rapid response to security incidents and preventing the escalation of security risks; achieving fine-grained permission control, allowing configuration of specific authorized API lists for individual applications, avoiding over-authorization, granting only the API permissions required for the normal operation of the application, reducing the risk of malicious applications launching attacks using redundant permissions, and further improving the security of the vehicle system; at the same time, the scope of authorized APIs can be flexibly adjusted according to application type and functional requirements to adapt to the application needs of different scenarios.

[0122] To facilitate better implementation of the application permission management method provided in this application embodiment, this application embodiment also provides an apparatus based on the above application permission management method. The meanings of the terms used are the same as in the above application permission management method, and specific implementation details can be found in the description of the method embodiment.

[0123] For example, such as Figure 5 The diagram shown is a structural schematic of an application permission management device provided in an embodiment of this application. The application permission management device may include a determination unit 301 and an authentication unit 302, as detailed below: The determining unit 301 is used to determine the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface; The authentication unit 302 is used to perform permission verification processing on the first interface call request based on the mapping relationship, which includes the correspondence between the application and at least one application programming interface that it can call.

[0124] In one embodiment, the authentication unit is used for: Based on the application identity credential information and mapping relationship of the target application, determine at least one target application programming interface that the target application has calling permission; Based on the target application programming interface, the first interface call request is subject to permission verification.

[0125] In one embodiment, the above-mentioned permission verification processing of the first interface call request based on the target application programming interface is specifically used for: If the target application programming interface includes the first application programming interface, the permission verification result of the first interface call request is determined to be passed; And / or, if the target application programming interface does not include the first application programming interface, determine that the permission verification result of the first interface call request is unsuccessful.

[0126] In one embodiment, based on the target application programming interface, the permission verification process for the first interface call request includes: If the first application programming interface is a high-risk interface and the vehicle to which the vehicle terminal belongs is in motion, the permission verification result of the first interface call request is determined to be unsuccessful. And / or, if the first application programming interface is a high-risk interface and the vehicle to which the vehicle terminal belongs is not in motion, the permission verification result of the first interface call request is determined to be passed.

[0127] In one embodiment, the application identity credential information includes at least one of the application identifier of the target application and signature feature information.

[0128] In one embodiment, the application passed the compliance audit test provided by the cloud corresponding to the vehicle terminal.

[0129] In one embodiment, if the permission verification process results in a pass, the application permission management device further includes: Write the application identifier of the target application and the interface identifier of the first application programming interface into the preset cache information; Based on the preset cache information, when a second interface call request initiated by the target application for the first application programming interface is subsequently received, the permission verification result of the second interface call request is determined to be passed.

[0130] In one embodiment, the application permission management device is further configured to: If the preset cache information meets the preset expiration conditions, the second interface call request is subject to permission verification based on the mapping relationship. The preset failure conditions include at least one of the following: the permissions of the target application are changed, the status of the vehicle where the in-vehicle terminal is located changes, and the target application is restarted.

[0131] In one embodiment, the application permission management device is further configured to: Upon receiving a permission revocation command for the target application issued by the cloud, the target mapping relationship corresponding to the target application is marked as deprecated. Upon receiving a third interface call request initiated by the target application for the second application programming interface, based on the marked target mapping relationship, the permission verification result of the third interface call request is determined to be unsuccessful.

[0132] As described above, in this embodiment, the determining unit 301 determines the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface; the authentication unit 302 performs permission verification processing on the first interface call request based on the mapping relationship, which includes the correspondence between the application and at least one application programming interface that it can call. Thus, by determining the application programming interface that the target application has call permission based on the preset mapping relationship, permission verification processing is performed on the first interface call request based on the mapping relationship, improving the compatibility between the application and the vehicle system. This avoids the situation where the hash value of the application package is changed during the application and application programming interface authorization process, which would prevent subsequent incremental updates of the application from proceeding normally, thereby improving the efficiency of permission management for vehicle applications.

[0133] Accordingly, embodiments of this application also provide an electronic device, such as... Figure 6 As shown, Figure 6This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 400 includes a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, and a computer program stored in the memory 402 and executable on the processor. The processor 401 and the memory 402 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0134] The processor 401 is the control center of the electronic device 400. It connects various parts of the electronic device 400 through various interfaces and lines. By running or loading software programs and / or units stored in the memory 402, and calling data stored in the memory 402, it executes various functions of the electronic device 400 and processes data. The processor 401 may be a CPU, GPU, network processor (NP), etc., and can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0135] In this embodiment, the processor 401 in the electronic device 400 loads the instructions corresponding to the processes of one or more applications into the memory 402 according to the following steps, and the processor 401 runs the applications stored in the memory 402 to realize various functions, such as: Identify the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface; based on the mapping relationship, perform permission verification processing on the first interface call request, the mapping relationship including the correspondence between the application and at least one application programming interface that it can call.

[0136] Furthermore, the various functions implemented by running the application stored in memory 402 can also be found in the description of the foregoing embodiments, and will not be repeated here.

[0137] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0138] Optional, such as Figure 6 As shown, the electronic device 400 also includes: a touch display screen 403, a radio frequency circuit 404, an audio circuit 405, an input unit 406, and a power supply 407. The processor 401 is electrically connected to the touch display screen 403, the radio frequency circuit 404, the audio circuit 405, the input unit 406, and the power supply 407. Those skilled in the art will understand that... Figure 6The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0139] The touch display screen 403 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 403 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 401. It can also receive and execute commands from the processor 401. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 401 to determine the type of touch event. Subsequently, the processor 401 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and display panel can be integrated into the touch display screen 403 to achieve input and output functions. However, in some embodiments, the touch panel and display panel can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 403 can also be used as part of the input unit 406 to achieve input functions.

[0140] The radio frequency circuit 404 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0141] Audio circuit 405 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuit 405 can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuit 405, converted back into audio data, and then processed by processor 401 before being transmitted via radio frequency circuit 404 to, for example, another electronic device, or output to memory 402 for further processing. Audio circuit 405 may also include an earphone jack to provide communication between peripheral headphones and electronic devices.

[0142] The input unit 406 can be used to receive input target video and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0143] Power supply 407 is used to supply power to various components of electronic device 400. Optionally, power supply 407 can be logically connected to processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 407 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0144] although Figure 6 As not shown in the diagram, the electronic device 400 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0145] In the above embodiments, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be found in the relevant descriptions of other embodiments. It should be noted that the electronic device provided in this application embodiment and the application permission management method described in the above embodiments belong to the same concept, and its specific implementation process is detailed in the above method embodiments, and will not be repeated here.

[0146] As can be seen from the above, the electronic device provided in this application embodiment can determine the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface; based on the mapping relationship, it performs permission verification processing on the first interface call request, whereby the mapping relationship includes the correspondence between the application and at least one application programming interface that it can call. Thus, by determining the application programming interface that the target application has call permission for according to the preset mapping relationship, and thereby performing permission verification processing on the first interface call request based on the mapping relationship, the compatibility between the application and the vehicle system is improved. This avoids the situation where the hash value of the application package is changed during the application and application programming interface authorization process, which would prevent subsequent incremental updates of the application from proceeding normally, thereby improving the efficiency of permission management for vehicle applications.

[0147] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0148] Therefore, embodiments of this application provide a computer-readable storage medium, including a computer program. When the computer program is run on an electronic device, the computer program is used to cause the electronic device to execute any of the application permission management methods provided in embodiments of this application. For example, the computer program can execute the steps of the following application permission management method: Identify the first interface call request initiated by the target application running on the vehicle terminal for the first application programming interface; based on the mapping relationship, perform permission verification processing on the first interface call request, the mapping relationship including the correspondence between the application and at least one application programming interface that it can call.

[0149] Furthermore, the detailed steps of the above method can be found in the description of the foregoing embodiments, and will not be repeated here.

[0150] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0151] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0152] It should be noted that, in the data processing stage, the technical solution of this application has strictly limited the scope of data collection to the minimum necessary to achieve the technical objectives, preventing the acquisition of irrelevant information. For any user information to be collected, the data subject will be clearly informed and their consent obtained. Furthermore, technologies such as encrypted storage and access control are employed to strengthen data security and ensure the security and compliance of the entire data processing process. The technical model and decision-making mechanism are based on objective technical parameters and do not introduce unnecessary parameters such as gender or age that may lead to discrimination, resolutely eliminating algorithmic discrimination and upholding public order and good morals. In addition, the specification fully describes the technical implementation methods, application scenarios, and compliance protection details. The claims are consistent with the content of the specification, key compliance designs are clear and verifiable, and the overall technical design is guided by the protection of public interests and adherence to social ethics, without any circumstances that harm public interests or violate public order and good morals.

[0153] Since the computer program stored in the computer-readable storage medium can execute any of the application permission management methods provided in the embodiments of this application, it can achieve the beneficial effects that any of the application permission management methods provided in the embodiments of this application can achieve, as detailed in the preceding embodiments, and will not be repeated here.

[0154] According to one aspect of this application, a computer program product is also provided, comprising a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the methods provided in various optional implementations of the above embodiments.

[0155] In the above embodiments of the application permission management device, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the application permission management device, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the description of the application permission management method in the above embodiments, and will not be repeated here.

[0156] The foregoing has provided a detailed description of an application permission management method, apparatus, electronic device, vehicle, system, computer-readable storage medium, and computer program product provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An application permission management method, characterized in that, include: Determine the first interface call request initiated by the target application running on the vehicle terminal in response to the first application programming interface; Based on the application identity credential information and mapping relationship of the target application, determine at least one target application programming interface that the target application has calling permission; Based on the target application programming interface, the first interface call request is subject to permission verification processing, and the mapping relationship includes the correspondence between the application and at least one application programming interface that it can call; The step of performing permission verification processing on the first interface call request based on the target application programming interface includes: If the target application programming interface includes the first application programming interface, the first application programming interface is a high-risk interface, and the vehicle to which the vehicle terminal belongs is in motion, then the permission verification result of the first interface call request is determined to be unsuccessful. And / or, if the target application programming interface includes the first application programming interface, the first application programming interface is a high-risk interface, and the vehicle to which the vehicle terminal belongs is not in a driving state, the permission verification processing result of the first interface call request is determined to be passed.

2. The application permission management method as described in claim 1, characterized in that, The permission verification process for the first interface call request based on the target application programming interface includes: If the target application programming interface includes the first application programming interface, the permission verification result of the first interface call request is determined to be passed; And / or, if the target application programming interface does not include the first application programming interface, determine that the permission verification result of the first interface call request is unsuccessful.

3. The application permission management method as described in claim 1, characterized in that, The application identity credential information includes at least one of the target application's application identifier and signature feature information.

4. The application permission management method as described in claim 1, characterized in that, The application passed the compliance audit test provided by the cloud corresponding to the vehicle terminal.

5. The application permission management method as described in claim 1, characterized in that, If the permission verification process results in a pass, the method further includes: Write the application identifier of the target application and the interface identifier of the first application programming interface into the preset cache information; Based on the preset cache information, when a second interface call request initiated by the target application for the first application programming interface is subsequently received, the permission verification result of the second interface call request is determined to be passed.

6. The application permission management method as described in claim 5, characterized in that, Also includes: If the preset cache information meets the preset expiration conditions, the second interface call request is subject to permission verification based on the mapping relationship. The preset failure conditions include at least one of the following: the permissions of the target application are changed, the status of the vehicle where the in-vehicle terminal is located changes, and the target application is restarted.

7. The application permission management method as described in any one of claims 1 to 6, characterized in that, The method further includes: Upon receiving a permission revocation command for the target application issued by the cloud, the target mapping relationship corresponding to the target application is marked as deprecated. Upon receiving a third interface call request initiated by the target application for the second application programming interface, based on the marked target mapping relationship, the permission verification result of the third interface call request is determined to be unsuccessful.

8. An application permission management method, characterized in that, include: Based on the correspondence between the applications running on the vehicle terminal and at least one application programming interface that can be called, a mapping relationship is generated for each of the applications. The mapping relationship is sent to the vehicle terminal so that the vehicle terminal can determine the first interface call request initiated by the target application for the first application programming interface. Based on the application identity credential information of the target application and the mapping relationship, the vehicle terminal determines at least one target application programming interface for which the target application has call permission. If the target application programming interface includes the first application programming interface, the first application programming interface is a high-risk interface, and the vehicle to which the vehicle terminal belongs is in motion, the permission verification result of the first interface call request is determined to be failed. And / or, if the target application programming interface includes the first application programming interface, the first application programming interface is a high-risk interface, and the vehicle to which the vehicle terminal belongs is not in motion, the permission verification result of the first interface call request is determined to be passed.

9. The application permission management method as described in claim 8, characterized in that, The mapping relationship between the applications running on the vehicle terminal and at least one application programming interface that can be called is generated, including: Based on the application installation package of the application running on the vehicle terminal, identify at least one application programming interface that the application can call; Based on the application and its callable application programming interfaces, a mapping relationship is generated corresponding to the application.

10. The application permission management method as described in claim 9, characterized in that, The application installation package of the application running on the vehicle terminal identifies at least one application programming interface that the application can call, including: Based on the first candidate application programming interface and the second candidate application programming interface, at least one application programming interface that the application can call is determined. The first candidate application programming interface is obtained by performing static code analysis on the application installation package of the application, and the second candidate application programming interface is obtained by running the application based on the application installation package.

11. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1 to 10.

12. A vehicle, characterized in that, include: The electronic device as claimed in claim 11; Alternatively, a processor, the processor being configured to execute the application permission management method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 10.

Images