Installation package interface compatibility control method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of vehicle application technologies, and discloses an installation package interface compatibility control method and device, electronic equipment and a storage medium. The method comprises the following steps: when an interface of any Android application package APK is exposed, extracting an interface description language file; generating a semantic signature abstract corresponding to the interface according to the interface description language file; performing uniqueness verification on the semantic signature abstract, and generating an interface ID and a version number after the uniqueness verification is passed; when the first APK calls the interface ID exposed by the second APK, if the version number of the first APK and the version number of the second APK are different, semantic-level automatic adaptation operation is executed according to a preset adaptation rule; and at least after the semantic-level automatic adaptation operation is completed, establishing a connection calling relationship between the first APK and the second APK. According to the application, the security and compatibility of the APK interface can be improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle application technology, and in particular to an installation package interface compatible control method, device, electronic device, and storage medium. Background Technology

[0002] With the continuous upgrades of intelligent cockpits and in-vehicle infotainment systems, the vehicle software architecture is gradually evolving from a monolithic application model to a complex distributed platform with multiple modules and processes operating collaboratively. To improve functional scalability and development efficiency, more and more OEMs and ecosystem suppliers are adopting a modular architecture, developing, deploying, and maintaining functional modules such as navigation, voice assistants, vehicle control, and entertainment playback as independent APKs. These APKs are typically signed and managed by different development entities, and data interaction and function reuse between modules are achieved through the Binder / AIDL cross-process communication mechanism provided by the Android platform, thus forming a multi-source collaborative in-vehicle software ecosystem.

[0003] However, under this development model of parallel evolution of multiple APKs, existing technologies still have the following prominent problems:

[0004] 1. Insufficient granularity of interface signature compatibility detection

[0005] Existing detection tools mainly compare newly added or modified AIDL files, lacking precise analysis of semantic aspects such as method signatures, parameter types, and serialization field order.

[0006] When there are implicit changes in the interface definition (such as data structure adjustments or parameter type drift), the system often only exposes problems during the runtime phase, such as triggering exceptions like BadParcelableException and UNKNOWN_TRANSACTION, which seriously affects the stability of the vehicle's infotainment system.

[0007] 2. High risks associated with collaborative release of multiple APKs.

[0008] Each APK is typically maintained independently by different development teams, resulting in inconsistent version iteration schedules and a lack of global coordination mechanisms for interface changes.

[0009] Existing processes rely heavily on manual comparison or document synchronization, lacking automated methods for cross-APK interface compatibility verification. As a result, interface mismatch issues are often only discovered during integration testing or formal release, leading to rework and project delays.

[0010] 3. Lack of a unified mechanism for reporting differences and tracing interface evolution.

[0011] Current detection tools mostly output results in the form of logs or prompts, and the information is scattered and untraceable, failing to systematically present the history of interface evolution and compatibility changes.

[0012] Therefore, the development team has difficulty grasping the interface dependencies and their impact in a timely manner, which increases the complexity of iterative maintenance of in-vehicle software.

[0013] In summary, existing technologies cannot effectively solve the compatibility verification and collaborative release security issues of interface evolution in in-vehicle multi-APK systems. There is an urgent need for a technical solution that can automatically detect semantic differences in interfaces, track historical interface evolution, and support collaborative release decisions. Summary of the Invention

[0014] The purpose of this invention is to provide an installation package interface compatibility control method, device, electronic device, and storage medium to at least solve the compatibility verification and collaborative release security issues of interface evolution in vehicle-mounted multi-APK systems, thereby improving the security and compatibility of APK interfaces.

[0015] To address the aforementioned technical problems, in a first aspect, the present invention provides an installation package interface compatibility control method, comprising at least:

[0016] When an interface is exposed in any Android application package (APK), extract the interface description language file;

[0017] Generate a semantic signature digest corresponding to the interface based on the interface description language file;

[0018] Perform a uniqueness check on the semantic signature digest, and generate an interface ID and version number after the uniqueness check passes;

[0019] When the first APK calls the interface ID exposed by the second APK, if there is a difference in the version number between the first APK and the second APK, a semantic-level automatic adaptation operation is performed according to the preset adaptation rules.

[0020] At least after the semantic-level automatic adaptation operation is completed, the connection and call relationship between the first APK and the second APK is established.

[0021] Optionally, when the first APK calls the interface ID exposed by the second APK, if the version numbers of the first APK and the second APK differ, a semantic-level automatic adaptation operation is performed according to preset adaptation rules, specifically including:

[0022] When the first APK calls the interface ID exposed by the second APK, if there is a difference in the version number between the first APK and the second APK, the adaptation operation method is determined again.

[0023] If the adaptation operation method involves adding parameters, then the default values ​​should be filled in;

[0024] If the adaptation operation method is a parameter type change, then the parameter type is changed according to the target change type;

[0025] If the adaptation operation method is to delete parameters, then the input field corresponding to the first APK is ignored;

[0026] If the adaptation operation method is to extend the return value structure, then the mapping will be automatically downgraded or irrelevant fields will be truncated.

[0027] Optionally, after performing a uniqueness check on the semantic signature digest and generating the interface ID and version number after the uniqueness check passes, the method further includes:

[0028] When the first APK calls the interface ID exposed by the second APK, if there is no difference in the version number of the first APK and the second APK, then a connection call relationship between the first APK and the second APK is established.

[0029] Optionally, after the automatic adaptation operation at least at the semantic level is completed and the connection and call relationship between the first APK and the second APK is established, the method further includes:

[0030] An interface signature dependency graph is constructed based on all the connection call relationships, and a consistency check is performed on the version number of each APK interface ID based on the interface signature dependency graph;

[0031] If the verification passes, the publishing process is executed on the connection call relationship.

[0032] Optionally, after performing a consistency check on the version number of each APK interface ID based on all the connection call relationships, the method further includes:

[0033] If the verification fails, the connection call relationship is blocked, and a structured difference report is generated.

[0034] Optionally, after the step of executing the publish process for the connection call relationship if the verification passes, the method further includes:

[0035] If any of the interfaces exposed by an APK requires a version update, then the minimum set of secure releases for that APK is obtained to determine the update mode for that APK.

[0036] Secondly, the present invention also provides an installation package interface compatible control device, comprising at least:

[0037] The data extraction module is used to extract the interface description language file when the interface of any Android application package (APK) is exposed.

[0038] The summary generation module is used to generate a semantic signature summary corresponding to the interface based on the interface description language file;

[0039] The interface verification module is used to perform uniqueness verification on the semantic signature digest and generate an interface ID and version number after the uniqueness verification passes.

[0040] An automatic adaptation module is used to perform semantic-level automatic adaptation operations according to preset adaptation rules when the first APK calls the interface ID exposed by the second APK and the version numbers of the first APK and the second APK are different.

[0041] The connection establishment module is used to establish a connection call relationship between the first APK and the second APK after at least the semantic level automatic adaptation operation is completed.

[0042] Optionally, the automatic adaptation module is specifically used for:

[0043] When the first APK calls the interface ID exposed by the second APK, and there is a difference between the version numbers of the first APK and the second APK, the adaptation operation method is determined again; when the adaptation operation method is to add parameters, default values ​​are filled in; when the adaptation operation method is to change the parameter type, the parameter type is changed according to the target change type; when the adaptation operation method is to delete parameters, the input field corresponding to the first APK is ignored; and when the adaptation operation method is to expand the return value structure, irrelevant fields are automatically downgraded or truncated.

[0044] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the program to implement the steps of the installation package interface compatibility control method according to any one of the first aspects.

[0045] Fourthly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the installation package interface compatibility control method described in any one of the first aspects.

[0046] The technical solution provided by this invention firstly extracts the interface description language file when the interface of any Android application package (APK) is exposed; secondly, a semantic signature digest corresponding to the interface is generated based on the interface description language file; thirdly, a uniqueness check is performed on the semantic signature digest, and an interface ID and version number are generated after the uniqueness check passes; then, when the first APK calls the interface ID exposed by the second APK, if there is a difference between the version numbers of the first APK and the second APK, a semantic-level automatic adaptation operation is performed according to a preset adaptation rule; finally, at least after the semantic-level automatic adaptation operation is completed, a connection and call relationship between the first APK and the second APK is established.

[0047] Therefore, the embodiments of the present invention can generate semantic signature digests corresponding to interfaces based on interface description language files, and when the first APK calls the interface ID exposed by the second APK and there is a difference in the version numbers of the first APK and the second APK, the semantic signature digests can identify compatibility issues at the field level, type level and semantic level, which can significantly reduce the abnormal occurrence rate of APK runtime and improve the overall stability of the vehicle system. Attached Figure Description

[0048] Figure 1 This is a flowchart of an installation package interface compatibility control method provided in an embodiment of the present invention;

[0049] Figure 2 This is a flowchart of another installation package interface compatibility control method provided in an embodiment of the present invention;

[0050] Figure 3 This is a flowchart of another installation package interface compatibility control method provided in an embodiment of the present invention;

[0051] Figure 4 This is a schematic diagram of the structure of an installation package interface compatible control device provided in an embodiment of the present invention;

[0052] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0055] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0056] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0057] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0058] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0059] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0060] Figure 1This is a flowchart of an installation package interface compatibility control method provided by an embodiment of the present invention. This embodiment is applicable to at least various vehicle network module APK cross-process interface compatibility control scenarios. This installation package interface compatibility control method can be, but is not limited to, executed by the installation package interface compatibility control device in this embodiment as the execution subject. This execution subject can be implemented in software and / or hardware. Figure 1 As shown, the installation package interface compatibility control method includes at least the following steps:

[0061] S1. When the interface of any Android application package APK is exposed, extract the interface description language file.

[0062] In this context, "APK interface exposure" can be understood as any APK exposing its interface to the outside world. The interface description language file can be either an interface description file or an AIDL (Android's interface definition language for implementing inter-process communication (IPC)) definition.

[0063] S2. Generate a semantic signature digest corresponding to the interface based on the interface description language file.

[0064] The semantic signature digest can be an interface identifier, method name, parameter type, return value, exception declaration, and semantic vector features. It is understood that this embodiment may also set up a central repository to store the semantic signature digests of each exposed interface.

[0065] S3. Perform a uniqueness check on the semantic signature digest, and generate the interface ID and version number after the uniqueness check passes.

[0066] Uniqueness verification can involve checking for the existence of an interface with the same name, i.e., whether the interface has been saved. When a historical version of an interface with the same name is detected, a semantic-level signature comparison is required. If semantically incompatible changes are found (such as field deletion, parameter type changes, or structure redefinition), the developer needs to explicitly declare the new version interface and establish a version inheritance relationship. The interface ID can be generated by combining the APK package name, interface name, and namespace, for example: com.car.navservice.IaudioControl, used to uniquely identify the interface definition across the entire system. The version number can adopt semantic versioning rules (such as 1.0.0, 1.1.0, 2.0.0). It is understandable that the version number can also carry an additional field, compatibilityLevel, to identify the compatibility relationship between versions, such as: FULL_COMPATIBLE: fully compatible; PARTIAL_COMPATIBLE: field extensions exist but do not affect calls; INCOMPATIBLE: structural changes or semantic shifts exist.

[0067] S4. When the first APK calls the interface ID exposed by the second APK, if there is a difference in the version number of the first APK and the second APK, then a semantic-level automatic adaptation operation is performed according to the preset adaptation rules.

[0068] The version number difference could be that the first APK version is V1.1 and the second APK version is V1.2. Preset adaptation rules are used to accommodate the differences between different version numbers. These rules can be automatically generated by the system or maintained by the developer in the interface semantic signature traceability management module, thus supporting seamless compatibility of cross-version interface calls.

[0069] S5. At least after the semantic-level automatic adaptation operation is completed, establish the connection and call relationship between the first APK and the second APK.

[0070] Establishing a connection can involve creating a Binder connection and executing a call.

[0071] The technical solution provided in this embodiment firstly extracts the interface description language file when the interface of any Android application package (APK) is exposed; secondly, a semantic signature digest corresponding to the interface is generated based on the interface description language file; thirdly, a uniqueness check is performed on the semantic signature digest, and an interface ID and version number are generated after the uniqueness check passes; then, when the first APK calls the interface ID exposed by the second APK, if there is a difference between the version numbers of the first APK and the second APK, a semantic-level automatic adaptation operation is performed according to a preset adaptation rule; finally, at least after the semantic-level automatic adaptation operation is completed, a connection and call relationship between the first APK and the second APK is established.

[0072] Therefore, this embodiment can generate a semantic signature digest corresponding to the interface based on the interface description language file. When the first APK calls the interface ID exposed by the second APK, and the version numbers of the first and second APKs differ, it can identify field-level, type-level, and semantic-level compatibility issues based on the semantic signature digest. This can significantly reduce the error rate during APK runtime and improve the overall stability of the vehicle system.

[0073] Based on the above embodiments or implementation methods Figure 2 This is a flowchart of another installation package interface compatibility control method provided by an embodiment of the present invention. This embodiment is based on the above embodiment with additions and refinements. Figure 2 As shown, the installation package interface compatibility control method includes at least the following steps:

[0074] S1. When the interface of any Android application package APK is exposed, extract the interface description language file.

[0075] S2. Generate a semantic signature digest corresponding to the interface based on the interface description language file.

[0076] S3. Perform a uniqueness check on the semantic signature digest, and generate the interface ID and version number after the uniqueness check passes.

[0077] S6. When the first APK calls the interface ID exposed by the second APK, if there is no difference in the version numbers of the first APK and the second APK, then establish a connection and call relationship between the first APK and the second APK.

[0078] S41. When the first APK calls the interface ID exposed by the second APK, if there is a difference in the version number of the first APK and the second APK, the adaptation operation method is determined.

[0079] S42. If the adaptation operation method is to add parameters, then fill in the default values.

[0080] The function of filling in default values ​​can be achieved by iterating through the parameters of the new version of the second APK and automatically filling in default values ​​for new parameters that were not passed in from the first APK. Only parameters that are "new and have default values" will be processed, thus avoiding invalid operations.

[0081] S43. If the adaptation operation method is parameter type change, then change the parameter type according to the target change type.

[0082] Among them, changing the parameter type according to the target change type can be performed by performing a conversion based on the target change type (such as str→int), only processing parameters with type changes, and throwing a clear exception when the conversion fails, which makes it easier to locate the problem.

[0083] S44. If the adaptation operation method is to delete parameters, then ignore the input field corresponding to the first APK.

[0084] In this case, ignoring the input field corresponding to the first APK can mean ignoring the parameters passed in from the first APK that have been deleted or become optional in the new version of the second APK, and removing them directly from the input parameters.

[0085] S45. If the adaptation operation method is a return value structure extension, then automatically downgrade the mapping or truncate irrelevant fields.

[0086] Among them, automatic downgrade mapping or truncation of irrelevant fields can be used to retain only the return fields supported by the older version of the second APK.

[0087] S5. At least after the semantic-level automatic adaptation operation is completed, establish the connection and call relationship between the first APK and the second APK.

[0088] S7. Construct an interface signature dependency graph based on all connection call relationships, and perform consistency verification on the version number of each APK interface ID based on the interface signature dependency graph.

[0089] The interface signature dependency graph can be stored using an adjacency list or a directed graph to show the interface call relationships (caller, callee, interface signature) between APKs, as well as the inheritance and evolution relationships of different interface versions. Consistency verification can involve traversing each node of the dependency graph to verify the consistency between the interface version and the caller's adaptability; and verifying whether the caller has completed adaptation after the callee's interface version changes. A verification report can also be generated after the traversal is complete.

[0090] S8. If the verification passes, the publishing process will be executed on the connection call relationship.

[0091] S9. If the verification fails, prevent the connection call relationship and generate a structured difference report.

[0092] Step S9 can be understood as automatically blocking the release process when a semantic signature incompatibility is detected in the interface call chain (e.g., the caller depends on interface v1, while the callee upgrades to v2 and there are structural differences). At the same time, a structured difference report (JSON / HTML format) is generated, which includes a list of changed interfaces, affected callers, a description of semantic differences, and recommended adaptation strategies.

[0093] S10. If any interface exposed by an APK requires a version update, obtain the minimum secure release set of the APK to determine the APK's update mode.

[0094] The minimum secure release set can be determined by starting with the APK to be updated, traversing the interface signature dependency graph, and identifying all APKs affected by version changes. For example, if APK1's interface version is updated and this interface is called by APK2, further checks are made to see if APK2 is adapted to the new version of APK1: if not, APK2 needs to be added to the set. Update modes can include collaborative upgrades and independent releases. It's understandable that if only the APK to be updated exists within the minimum secure release set, it can be considered an independent release. In another implementation scenario, the calculation process for the minimum secure release set is as follows:

[0095] 1. Starting from the interface differential node, traverse downstream along the dependency topology;

[0096] 2. Mark all APK nodes that depend on older versions of this interface;

[0097] 3. Perform compatibility filtering to exclude modules that already have semantic adaptation layer support;

[0098] 4. Output the minimum secure release set (i.e. the set of APKs that must be updated synchronously).

[0099] Understandably, this mechanism can enable safe iteration of local modules without affecting the overall system stability, significantly reducing the risk and release cost of upgrading in-vehicle systems.

[0100] In a specific implementation scenario Figure 3 This is a flowchart of another installation package interface compatibility control method provided in an embodiment of the present invention. See [link / reference]. Figure 3 This embodiment can also construct an interface semantic signature traceability management module management center to centrally manage the semantic signatures, version evolution relationships, and compatibility rules of cross-process interfaces in a vehicle-mounted multi-APK system. This management center not only records the syntactic features of the interface but also includes parameter semantic descriptions and inter-interface dependencies, achieving semantic-level compatibility detection and traceable management. During interface registration, comparison, and version management, the management center performs the following steps:

[0101] 1. Interface Registration

[0102] During the build phase, the provider's APK calls the management center API to upload the interface definition file or an automatically generated semantic signature digest;

[0103] The system generates an InterfaceID based on the package name and interface name, and records the current build timestamp and APK version.

[0104] 2. Semantic signature comparison and compatibility determination

[0105] The management center compares the newly uploaded signature with the semantic digests of historical versions, using semantic similarity algorithms and field-level structural difference.

[0106] Classification based on comparison results:

[0107] If FULL_COMPATIBLE: The system makes incremental records based on the original version;

[0108] If PARTIAL_COMPATIBLE: coexistence is allowed, and the recommended adaptation strategy is marked;

[0109] If INCOMPATIBLE: Automatically generate a new version number and require the caller to update dependencies synchronously or use a semantic adaptation layer for compatibility.

[0110] 3. Version Inheritance and Tracking

[0111] The management center maintains the inheritance chain (VersionGraph) of interface versions and updates the evolution trajectory with each change;

[0112] It supports querying the historical versions, caller dependencies, and compatibility information of any interface.

[0113] 4. Signature verification during invocation

[0114] Before running or during the build process, the calling APK queries the management center to obtain the latest semantic signature digest of the target interface.

[0115] The semantic adaptation layer is invoked to verify the consistency of parameter types, order, and versions based on the summary information. If a difference is detected, the adaptation rules are automatically applied.

[0116] Furthermore, the semantic adaptation layer is deployed within each APK as an intermediate component of the interface call chain, responsible for performing semantic signature verification and version compatibility adaptation during cross-process calls.

[0117] This layer interacts with the interface semantic signature traceability management module to perceive interface semantic differences in real time, and automatically generates parameter mappings and data transformation strategies using the semantic adaptation inference engine, thereby ensuring call compatibility and execution consistency between different version interfaces. The call semantic adaptation layer mainly includes the following functional modules:

[0118] 1. The Interface Signature Synchronization Module (Signature Sync Manager) is used to periodically or on-demand synchronize the semantic signature digests of the interfaces that this APK depends on from the management center; and to maintain a local interface signature cache (Local SignatureCache), and verify the signature version before calling. The Interface Signature Synchronization Module supports differential updates, reducing network load and dependency conflicts during build.

[0119] 2. The Semantic Adaptation Engine is used to automatically generate adaptation strategies based on interface signature differences; and to analyze the field change types of the caller and callee interfaces based on the Semantic Delta Matrix; and to perform the following types of semantic adaptation through the Rule-based Reasoner: field completion: automatically filling in default values ​​based on the semantic tags of parameters (such as "volume" and "direction"); type conversion: performing data type transformations (such as int to float, enum to string) under the premise of semantic equivalence; field remapping: automatically establishing mapping relationships when interface fields are renamed but semantic tags remain consistent; and structural degradation: performing field truncation or degradation mapping for additional fields in the new version's return value to maintain caller resolvability.

[0120] 3. The Adaptation Policy Table stores the adaptation rules generated by the inference engine, organized in key-value pairs: <Interface ID, Caller Version, Provider Version>, [List of Mapping Rules]. Furthermore, rules can be automatically generated by the system or manually maintained and verified by developers in the management center.

[0121] 4. Dynamic Proxy Layer: This layer utilizes the Binder mechanism or AIDL proxy to inject adaptation logic at runtime. It also automatically switches to the semantic adaptation engine to perform mapping conversion when an interface version mismatch is detected. This ensures that the caller can be compatible with multiple interface versions without modifying the business code.

[0122] Furthermore, the typical execution flow of calling the semantic adaptation layer is as follows:

[0123] 1. Interface verification phase

[0124] Before initiating a cross-APK interface request, the caller first verifies the target interface signature in the local cache;

[0125] If the cached version matches the latest signature from the management center, then call it directly;

[0126] If a signature difference is detected, the semantic adaptation reasoning process is triggered.

[0127] 2. Adaptation rule generation stage

[0128] The semantic adaptation inference engine loads the historical version signature of the target interface;

[0129] An adaptation strategy is generated by comparing parameter structures using a semantic difference matrix.

[0130] Store the strategy in the parameter mapping strategy table for quick reference in subsequent calls.

[0131] 3. Dynamic Execution Phase

[0132] The proxy layer is invoked to inject conversion logic before Binder communication;

[0133] The input parameters are converted into a format that the callee can recognize by the semantic adaptation layer.

[0134] The API return result is then reverse-engineered and transmitted back to the caller.

[0135] 4. Result Validation and Caching Stage

[0136] After the call is completed, the adaptation layer verifies the integrity of the returned result structure and the consistency of the type;

[0137] If the execution is successful, the mapping strategy will be cached as a reusable template for subsequent calls to the same interface.

[0138] Furthermore, this embodiment also includes a consistency verification module (Release Consistency Validator, hereinafter referred to as the "verification module") deployed in the continuous integration / continuous delivery (CI / CD) pipeline of the vehicle software, which is used to automatically detect the interface semantic compatibility between each APK during the system build and release phases, and ensure the correctness and stability of the multi-module collaborative call relationship.

[0139] This module works closely with the interface semantic signature traceability management module and the semantic adaptation layer to form an end-to-end interface evolution security verification system.

[0140] The release consistency verification module mainly includes the following four core sub-modules:

[0141] 1. The Interface Difference Analysis Engine (Signature Diff Analyzer) is used to obtain the interface semantic signature digests of all APKs to be released from the management center; and to compare the signature differences between the build version and the current release version to generate a semantic difference description file (Semantic Delta Report).

[0142] The differential results include multi-level classifications such as method addition, parameter change, return value type adjustment, structure expansion, and semantic drift.

[0143] 2. The Dependency Topology Analyzer is used to construct the dependency topology between APKs based on the interface call relationship graph maintained by the management center; analyze the interface dependency direction and version binding relationship of each node in the call chain; and identify broken nodes in the topology (i.e., the interface version that the caller depends on has been replaced or deleted in the provider).

[0144] 3. The Compatibility Propagation Engine is used to perform compatibility propagation inference based on semantic difference results and dependency topology; calculate the impact of interface changes on downstream callers and mark the set of affected APKs; and map compatibility levels (fully compatible, partially compatible, incompatible) to visual topology color labels for report generation.

[0145] 4. Release Guard & Report Generator module: When incompatible interface changes are detected, it automatically blocks subsequent release steps in the CI / CD pipeline; generates structured difference reports (JSON, HTML, and PDF formats), including: a list of incompatible interfaces, a list of affected APKs and dependency chains, semantic difference descriptions and automatically recommended adaptation strategies; and generates a feasible minimum security release set recommendation.

[0146] Furthermore, the complete execution flow of the consistency verification module is as follows:

[0147] (1) Signature extraction and differential analysis

[0148] When a build task is started in the CI / CD pipeline, the system automatically calls the management center API to obtain the latest semantic signature digest for each APK; further, it calls the interface differential analysis engine to compare the signature information of the upcoming release version with the current online version; finally, it outputs a semantic differential description file, recording the changes and the level of difference.

[0149] (2) Dependency topology construction and propagation analysis

[0150] This involves calling the dependency topology analyzer to resolve the call dependencies between the current APKs; finally, it performs an impact range analysis on the differential interfaces to calculate the set of all directly or indirectly affected callers.

[0151] (3) Compatibility reasoning and risk assessment

[0152] The system uses the compatibility propagation module to perform inference based on the semantic rule table (maintained by the management center) to determine the compatibility level of each dependency path. Finally, if a "structural incompatibility" or "semantic drift" type change is detected, the system immediately marks it as a high-risk release.

[0153] (4) Release blocking and report generation

[0154] When a high-risk change exists, the verification module sends a blocking signal to the CI / CD system to prevent further deployment and simultaneously generates an "Interface Compatibility Difference Analysis Report," which includes: an impact analysis diagram (topology visualization), difference details (method-level change description), recommended handling solutions (adaptation strategies or synchronous upgrade suggestions), and the calculated minimum safe release set.

[0155] III. Minimum Security Release Set Calculation Mechanism

[0156] The verification module uses a topology propagation algorithm to calculate the minimum set of synchronized releases required for the system to maintain operational consistency under specific interface changes.

[0157] The calculation process is as follows:

[0158] 1. Starting from the interface differential node, traverse downstream along the dependency topology;

[0159] 2. Mark all APK nodes that depend on older versions of this interface;

[0160] 3. Perform compatibility filtering to exclude modules that already have semantic adaptation layer support;

[0161] 4. Output the minimum secure release set (i.e. the set of APKs that must be updated synchronously).

[0162] This mechanism enables safe iteration of local modules without affecting the overall system stability, significantly reducing the risk and release cost of upgrading in-vehicle systems.

[0163] Furthermore, in this embodiment, the CooperativeVersion Controller & Topology Analyzer (hereinafter referred to as the "Version Collaboration Module") is used to dynamically manage the interface dependencies and version compatibility status between APKs in an in-vehicle multi-module environment.

[0164] This module enables global modeling, real-time analysis, and version collaborative control across APK dependencies by constructing an interface call topology graph, thereby ensuring that the system maintains stable cross-process call capabilities during continuous iteration.

[0165] The version collaboration module consists of the following key components:

[0166] 1. Interface Dependency Modeler: This tool extracts interface call relationships from the semantic signature data and call logs of each APK. It also automatically constructs an Interface Dependency Graph (IDG), where nodes represent APK modules or interface entities, directed edges represent call dependencies, and edge attributes record version numbers, interface compatibility levels, and adaptation status. Topology data is stored in a graph database (such as Neo4j or a self-developed structure).

[0167] 2. Version State Monitor: This monitors the current version, known compatibility range, and historical evolution trajectory of each APK in real time. Furthermore, it combines semantic signature traceability data provided by the management center to form a global version map. Finally, it generates a network that supports the visualization of version dependencies and compatibility relationships between APKs.

[0168] 3. Topology Delta Analyzer: This analyzes topology changes and their impact on dependency chains during any APK upgrade; performs topology-level "impact propagation" calculations to identify all directly or indirectly affected module nodes; and outputs a difference report and triggers subsequent compatibility verification or release strategy evaluation.

[0169] 4. The Version Coordination Engine combines topology differential analysis results with semantic compatibility inference results to calculate the Minimal Safe Release Set; and executes version locking and dependency freezing strategies when multiple APKs are scheduled for asynchronous upgrades; temporarily freezes upstream interface versions if downstream modules are not yet adapted; and triggers automatic adaptation layer loading if partial compatibility is detected. It is evident that the Version Coordination Engine supports a multi-version coexistence mechanism, enabling the system to dynamically route requests between different version interfaces, ensuring a smooth transition.

[0170] The workflow of the version collaboration module includes the following steps:

[0171] (1) Construction of topology data

[0172] That is, firstly, the system periodically synchronizes interface signatures and version information from the management center; secondly, it extracts interface dependencies from build-time metadata or runtime call logs; and finally, it builds an interface dependency topology graph and stores it in the topology database.

[0173] (2) Version change awareness and differential calculation

[0174] That is, when any APK is upgraded or rebuilt, the topology analyzer compares its old and new dependency structures; secondly, it automatically detects newly added, deleted or replaced interface nodes and calculates the topology difference set; finally, it performs semantic signature comparison on the changed nodes and marks the compatibility level.

[0175] (3) Dependence propagation and impact analysis

[0176] That is, firstly, the version change information is propagated downstream along the topology edge; secondly, the affected call chain and module set are calculated; finally, based on the semantic adaptation layer status, it is determined which calls can be automatically compatible and which require manual adaptation or collaborative upgrade.

[0177] (4) Version collaboration strategy decision

[0178] First, the decision engine calculates the minimum safe release set based on the propagation results; second, it outputs a release plan suggestion (synchronous update or delayed upgrade); finally, if there is a need for multiple versions to coexist, the system dynamically configures the interface routing strategy table to achieve parallel interface support.

[0179] Therefore, this embodiment can generate semantic signature digests corresponding to interfaces based on interface description language files. When the first APK calls the interface ID exposed by the second APK, and the version numbers of the first APK and the second APK differ, it can identify field-level, type-level, and semantic-level compatibility issues based on the semantic signature digests, significantly reducing the runtime exception rate and improving the overall stability of the vehicle system. On the other hand, this embodiment supports multi-APK version collaboration and minimum secure release set reasoning. Through cross-APK interface topology analysis, it can automatically calculate the minimum secure release set of the system under specific interface changes, enabling phased upgrades and multi-version coexistence, reducing the risk of collaborative releases. Furthermore, this embodiment has an automated consistency verification and report generation mechanism, which can automatically perform interface semantic comparison, dependency topology verification, and compatibility verification in the CI / CD release process, generating structured risk reports and change summaries, significantly reducing manual analysis costs and improving development and testing efficiency.

[0180] Figure 4 This is a schematic diagram of an installation package interface compatibility control device provided in an embodiment of the present invention. This embodiment is at least applicable to various vehicle network module APK cross-process interface compatibility control scenarios. This installation package interface compatibility control device can be implemented in software and / or hardware. Figure 4 As shown, the installation package interface compatible control device includes at least:

[0181] The data extraction module 110 is used to extract the interface description language file when the interface of any Android application package APK is exposed.

[0182] The summary generation module 120 is used to generate a semantic signature summary corresponding to the interface based on the interface description language file.

[0183] The interface verification module 130 is used to perform uniqueness verification on the semantic signature digest and generate the interface ID and version number after the uniqueness verification is passed.

[0184] The automatic adaptation module 140 is used to perform semantic-level automatic adaptation operations according to preset adaptation rules when the first APK calls the interface ID exposed by the second APK, if there is a difference in the version numbers of the first APK and the second APK.

[0185] The connection establishment module 150 is used to establish a connection call relationship between the first APK and the second APK, at least after the semantic-level automatic adaptation operation is completed.

[0186] Optionally, the automatic adaptation module 140 is specifically used for:

[0187] When the interface ID exposed by the first APK calls the second APK, and there is a difference in the version numbers of the first APK and the second APK, continue to determine the adaptation operation method; when the adaptation operation method is to add parameters, fill in the default value; when the adaptation operation method is to change the parameter type, change the parameter type according to the target change type; when the adaptation operation method is to delete parameters, ignore the input field corresponding to the first APK; and when the adaptation operation method is to expand the return value structure, automatically downgrade the mapping or truncate irrelevant fields.

[0188] Optionally, the connection establishment module 150 is also used for:

[0189] When the first APK calls the interface ID exposed by the second APK, and there is no difference in the version numbers of the first APK and the second APK, a connection call relationship is established between the first APK and the second APK.

[0190] Optionally, it also includes:

[0191] The release verification module 160 is used to construct an interface signature dependency graph based on all connection call relationships, and perform consistency verification on the version number of each APK interface ID based on the interface signature dependency graph; and, when the consistency verification passes, execute the release process on the connection call relationships.

[0192] Optionally, the publication verification module 160 is also used for:

[0193] If the consistency check fails, prevent the connection call relationship and generate a structured difference report.

[0194] Optionally, it also includes:

[0195] Version update module 170 is used to obtain the minimum secure release set of an APK to determine the APK's update mode when any interface exposed by an APK requires a version update.

[0196] The technical solution provided in this embodiment firstly extracts the interface description language file by means of a data extraction module when the interface of any Android application package (APK) is exposed; further, the semantic signature digest corresponding to the interface is generated by the digest generation module based on the interface description language file; further, the uniqueness of the semantic signature digest is verified by the interface verification module, and an interface ID and version number are generated after the uniqueness verification is passed; further, when the interface ID exposed by the first APK calls the second APK, and there is a difference between the version numbers of the first APK and the second APK, the semantic-level automatic adaptation operation is performed by the automatic adaptation module according to the preset adaptation rules; finally, at least after the semantic-level automatic adaptation operation is completed, the connection call relationship between the first APK and the second APK is established by the connection establishment module.

[0197] Therefore, this embodiment can generate a semantic signature digest corresponding to the interface based on the interface description language file. When the first APK calls the interface ID exposed by the second APK and there is a difference in the version numbers of the first APK and the second APK, it can identify field-level, type-level and semantic-level compatibility issues based on the semantic signature digest. This can significantly reduce the occurrence rate of APK runtime anomalies and improve the overall stability of the vehicle system.

[0198] This embodiment provides an electronic device. Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 5 The electronic device 1000 includes a processor 1001 and a memory 1002. The memory 1002 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 1001, the steps in any of the above installation package interface compatible control methods are performed. Through the above technical solution, the processor 1001 and the memory 1002 are interconnected and communicate with each other through a communication bus and / or other forms of connection mechanism (not shown). The memory 1002 stores a computer program that can be executed by the processor. When the electronic device 1000 is running, the processor 1001 executes the computer program to execute the installation package interface compatibility control method in any optional implementation of the above embodiments, so as to at least achieve the following functions: when the interface of any Android application package APK is exposed, extract the interface description language file; generate a semantic signature digest corresponding to the interface according to the interface description language file; perform a uniqueness check on the semantic signature digest and generate an interface ID and version number after the uniqueness check passes; when the first APK calls the interface ID exposed by the second APK, if there is a difference between the version numbers of the first APK and the second APK, perform a semantic-level automatic adaptation operation according to a preset adaptation rule; at least after the semantic-level automatic adaptation operation is completed, establish a connection and call relationship between the first APK and the second APK.

[0199] This embodiment provides a computer-readable storage medium storing a computer program. When executed by a processor, the program implements the installation package interface compatibility control method provided in all embodiments of this application: when the interface of any Android application package (APK) is exposed, an interface description language file is extracted; a semantic signature digest corresponding to the interface is generated based on the interface description language file; a uniqueness check is performed on the semantic signature digest, and an interface ID and version number are generated after the uniqueness check passes; when the first APK calls the interface ID exposed by the second APK, if there is a difference between the version numbers of the first APK and the second APK, a semantic-level automatic adaptation operation is performed according to a preset adaptation rule; at least after the semantic-level automatic adaptation operation is completed, a connection and call relationship between the first APK and the second APK is established.

[0200] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0201] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0202] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0203] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0204] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for controlling the compatibility of an installation package interface, characterized in that, At least including: When an interface is exposed in any Android application package (APK), extract the interface description language file; Generate a semantic signature digest corresponding to the interface based on the interface description language file; Perform a uniqueness check on the semantic signature digest, and generate an interface ID and version number after the uniqueness check passes; When the first APK calls the interface ID exposed by the second APK, if there is a difference in the version number between the first APK and the second APK, a semantic-level automatic adaptation operation is performed according to the preset adaptation rules. At least after the semantic-level automatic adaptation operation is completed, the connection and call relationship between the first APK and the second APK is established.

2. The installation package interface compatibility control method according to claim 1, characterized in that, When the first APK calls the interface ID exposed by the second APK, if the version numbers of the first APK and the second APK differ, a semantic-level automatic adaptation operation is performed according to preset adaptation rules, specifically including: When the first APK calls the interface ID exposed by the second APK, if there is a difference in the version number between the first APK and the second APK, the adaptation operation method is determined again. If the adaptation operation method involves adding parameters, then the default values ​​should be filled in; If the adaptation operation method is a parameter type change, then the parameter type is changed according to the target change type; If the adaptation operation method is to delete parameters, then the input field corresponding to the first APK is ignored; If the adaptation operation method is to extend the return value structure, then the mapping will be automatically downgraded or irrelevant fields will be truncated.

3. The installation package interface compatibility control method according to claim 1, characterized in that, After performing a uniqueness check on the semantic signature digest and generating the interface ID and version number after the uniqueness check passes, the method further includes: When the first APK calls the interface ID exposed by the second APK, if there is no difference in the version number of the first APK and the second APK, then a connection call relationship between the first APK and the second APK is established.

4. The installation package interface compatibility control method according to claim 1, characterized in that, After the semantic-level automatic adaptation operation is completed and the connection and call relationship between the first APK and the second APK is established, the method further includes: An interface signature dependency graph is constructed based on all the connection call relationships, and a consistency check is performed on the version number of each APK interface ID based on the interface signature dependency graph; If the verification passes, the publishing process is executed on the connection call relationship.

5. The installation package interface compatibility control method according to claim 4, characterized in that, After performing a consistency check on the version number of each APK interface ID based on all the connection call relationships, the method further includes: If the verification fails, the connection call relationship is blocked, and a structured difference report is generated.

6. The installation package interface compatibility control method according to claim 4, characterized in that, After the step of executing the publish process for the connection call relationship if the verification passes, the method further includes: If any of the interfaces exposed by an APK requires a version update, then the minimum set of secure releases for that APK is obtained to determine the update mode for that APK.

7. An installation package interface compatible control device, characterized in that, At least including: The data extraction module is used to extract the interface description language file when the interface of any Android application package (APK) is exposed. The summary generation module is used to generate a semantic signature summary corresponding to the interface based on the interface description language file; The interface verification module is used to perform uniqueness verification on the semantic signature digest and generate an interface ID and version number after the uniqueness verification passes. An automatic adaptation module is used to perform semantic-level automatic adaptation operations according to preset adaptation rules when the first APK calls the interface ID exposed by the second APK and the version numbers of the first APK and the second APK are different. The connection establishment module is used to establish a connection call relationship between the first APK and the second APK after at least the semantic level automatic adaptation operation is completed.

8. The installation package interface compatible control device according to claim 7, characterized in that, The automatic adaptation module is specifically used for: When the first APK calls the interface ID exposed by the second APK, and there is a difference between the version numbers of the first APK and the second APK, the adaptation operation method is determined again; and when the adaptation operation method is to add parameters, the default value is filled in. Furthermore, when the adaptation operation mode is parameter type change, the parameter type is changed according to the target change type; and when the adaptation operation mode is parameter deletion, the input field corresponding to the first APK is ignored; and when the adaptation operation mode is return value structure expansion, irrelevant fields are automatically downgraded or truncated.

9. An electronic device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the installation package interface compatibility control method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the installation package interface compatibility control method according to any one of claims 1 to 6.

Images