CN114328270B - OTA upgrade detection method based on SOA service and readable storage medium - Google Patents
OTA upgrade detection method based on SOA service and readable storage medium Download PDFInfo
- Publication number
- CN114328270B CN114328270B CN202210068216.6A CN202210068216A CN114328270B CN 114328270 B CN114328270 B CN 114328270B CN 202210068216 A CN202210068216 A CN 202210068216A CN 114328270 B CN114328270 B CN 114328270B
- Authority
- CN
- China
- Prior art keywords
- service
- version
- dependent
- information
- soa
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 61
- 230000001419 dependent effect Effects 0.000 claims description 115
- 238000000034 method Methods 0.000 abstract description 18
- 230000008569 process Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 206010063385 Intellectualisation Diseases 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
Abstract
The invention relates to the technical field of SOA (service oriented architecture) service, in particular to an OTA (over the air) upgrade detection method based on SOA service and a readable storage medium. The method comprises the following steps: acquiring an upgrade detection instruction of a current service; version information of each service is obtained; detecting version compatibility of the current service based on the version information of each service, and generating corresponding upgrading information according to the version compatibility detection result; and upgrading the current service based on the corresponding upgrading information. The invention also discloses a readable storage medium. The OTA upgrade detection method based on SOA service can be suitable for OTA upgrade detection after SOA service, so that the effectiveness and the comprehensiveness of SOA service version compatibility detection can be considered.
Description
Technical Field
The invention relates to the technical field of SOA (service oriented architecture) service, in particular to an OTA (over the air) upgrade detection method based on SOA service and a readable storage medium.
Background
Software-defined automobiles have become an industry consensus, and based on the requirements of digitization and intellectualization, software architecture has begun to be designed in Service-oriented architecture (Service-OrientedArchitecture, SOA). Each domain (vehicle control, cabin, electronic and electric architecture and the like) of the automobile provides own capability in an SOA service mode to generate SOA services, each SOA service can be used at will under the condition of permission, one SOA service is based on the running condition of other SOA services, and the service is called as a service dependence, and the corresponding depended service is called as a service dependence.
Based on the above, version compatibility detection between SOA services of the respective domains becomes particularly important. For this reason, chinese patent publication No. CN111562935B discloses an OTA security upgrade system and its upgrade method, and the OTA platform upgrade method includes security upgrade management, security version management, version download management and security control; the OTA terminal upgrading method is matched with the OTA platform function, the functions of corresponding upgrade version file key acquisition and processing, upgrade precondition judgment and preamble operation, security key request management and upgrade process state detection rule are provided for each intelligent part equipment upgrade, and the OTA terminal integrates the operation management for a plurality of intelligent parts.
The OTA upgrading method in the prior art realizes the OTA safe upgrading of the multi-type intelligent parts through the standardized equipment upgrading process management. However, the existing OTA upgrading method focuses on describing an OTA security upgrading system and a security mechanism in the OTA upgrading process, but does not describe version compatibility detection during OTA upgrading, and the method cannot be effectively applied to OTA upgrading detection after SOA service, so that the effectiveness of SOA service version compatibility detection is poor. Meanwhile, in practical application, there are cases that multiple SOA services depend on the same SOA service and the dependent versions of the multiple SOA services on the same dependent service are inconsistent, and at this time, version compatibility among the multiple SOA services needs to be detected so as to ensure the comprehensiveness of the detection of the version compatibility of the SOA services. Therefore, how to design a method suitable for detecting OTA upgrade after SOA service is a technical problem to be solved.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to solve the technical problems that: the OTA upgrade detection method based on SOA service is suitable for OTA upgrade detection after SOA service, so that the effectiveness and the comprehensiveness of SOA service version compatibility detection are considered.
In order to solve the technical problems, the invention adopts the following technical scheme:
An OTA upgrade detection method based on SOA service comprises the following steps:
s1: acquiring an upgrade detection instruction of a current service;
s2: version information of each service is obtained;
S3: detecting version compatibility of the current service based on the version information of each service, and generating corresponding upgrading information according to the version compatibility detection result;
S4: and upgrading the current service based on the corresponding upgrading information.
Preferably, in step S3, version compatibility detection is performed on the current service by:
s301: reading a configuration file of the current service, and analyzing to obtain primary dependent service information of the current service; the primary dependent service information comprises each primary dependent service and a corresponding primary dependent version;
302: reading configuration files of all primary dependent services, analyzing to obtain secondary dependent service information of all primary dependent services, and taking the primary dependent services with the secondary dependent service information as target services; the secondary dependent service information comprises each secondary dependent service and a corresponding secondary dependent version;
S303: determining whether the primary dependent version of the current service for each primary dependent service is version compatible with the version of the corresponding primary dependent service: if yes, executing S304; otherwise, the current service is not compatible with the primary dependent service version, and does not have version compatibility;
S304: determining whether the same secondary dependent service and primary dependent service exist: if yes, the same secondary dependent service and primary dependent service are used as common services, and S305 is executed; otherwise, the current service has version compatibility;
S305: determining whether the current service and the target service are version compatible for the common service based on the primary dependent version of the current service for the common service and the secondary dependent version of the target service for the common service: if yes, the current service has version compatibility; otherwise, the current service does not have version compatibility.
Preferably, in step S303, when the current service is not compatible with the primary dependent service version, upgrade information capable of satisfying compatibility of the current service with the corresponding primary dependent service version is generated based on version information of the corresponding primary dependent service.
Preferably, in step S304, when the current service and the target service are not compatible with the common service version, upgrade information capable of satisfying the compatibility of the current service and the target service with the common service version is generated based on the secondary dependent version information of the target service with the common service.
Preferably, the configuration file comprises a predefined version dependent configuration.
Preferably, the version dependent configuration includes, but is not limited to, service name, version information, and dependent service information.
Preferably, the dependent service information includes, but is not limited to, the name of the dependent service, and the corresponding predefined dependent version rules.
Preferably, the dependency version rule specifies dependency version information or dependency version range information of the service for the corresponding dependency service.
Preferably, when there is a difference set between the sections of the dependent version difference or the dependent version range of the two services, it is determined that the two service versions are not compatible.
The invention also discloses a readable storage medium, on which a computer management program is stored, which realizes the steps of the OTA upgrade detection method based on SOA service of the invention when being executed by a processor.
Compared with the prior art, the OTA upgrade detection method and the readable storage medium have the following beneficial effects:
According to the invention, the SOA service sends the upgrade detection instruction and the version compatibility of the corresponding SOA service is detected based on the version information of each SOA service, so that the version compatibility detection of the SOA service can be realized, and the method is applicable to OTA security upgrade detection after SOA service is implemented, thereby improving the effectiveness of the version compatibility detection of the SOA service. Meanwhile, the version compatibility detection of the corresponding SOA service is realized by judging the version compatibility of the current service and the primary dependent service and the version compatibility of the current service and the target service for the common service, so that when a plurality of SOA services depend on the same SOA service and the dependent versions are inconsistent, the version compatibility among the plurality of SOA services can be effectively identified, and the comprehensiveness of the version compatibility detection of the SOA service can be improved.
Drawings
For the purpose of making the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further detail with reference to the accompanying drawings, in which:
FIG. 1 is a logic block diagram of an OTA upgrade detection method based on SOA servicing;
FIG. 2 is a main flow chart of an OTA upgrade detection method based on SOA servicing;
FIG. 3 is a schematic diagram of scenario one;
fig. 4 is a schematic diagram of scenario two.
Detailed Description
The following is a further detailed description of the embodiments:
embodiment one:
the embodiment discloses an OTA upgrade detection method based on SOA service.
As shown in fig. 1, the method for detecting OTA upgrade based on SOA service comprises the following steps:
S1: acquiring an (OTA) upgrade detection instruction of a current (SOA) service;
s2: acquiring version information of each (SOA) service (SOA service);
S3: performing version compatibility detection on the current (SOA) service based on the version information of each (SOA) service, and generating corresponding upgrading information according to the version compatibility detection result;
S4: and (OTA) upgrading the current (SOA) service based on the corresponding upgrading information.
Specifically, version compatibility detection is performed on the current service by the following steps:
s301: reading a configuration file of the current service, and analyzing to obtain primary dependent service information of the current service; the primary dependent service information comprises each primary dependent service and a corresponding primary dependent version;
302: reading configuration files of all primary dependent services, analyzing to obtain secondary dependent service information of all primary dependent services, and taking the primary dependent services with the secondary dependent service information as target services; the secondary dependent service information comprises each secondary dependent service and a corresponding secondary dependent version;
S303: determining whether the primary dependent version of the current service for each primary dependent service is version compatible with the version of the corresponding primary dependent service: if yes, executing S304; otherwise, the current service is not compatible with the primary dependent service version, and does not have version compatibility;
S304: determining whether the same secondary dependent service and primary dependent service exist: if yes, the same secondary dependent service and primary dependent service are used as common services, and S305 is executed; otherwise, the current service has version compatibility;
S305: determining whether the current service and the target service are version compatible for the common service based on the primary dependent version of the current service for the common service and the secondary dependent version of the target service for the common service: if yes, the current service has version compatibility; otherwise, the current service does not have version compatibility.
It should be noted that, the method for detecting OTA upgrade based on SOA service of the present invention can generate corresponding software codes or software services in a program programming manner, so that the method can be run and implemented on a server and a computer.
Specifically, as shown in fig. 2, when the vehicle starts (for example, other triggering mechanisms may be used to start the upgrade detection program), the SOA service a initiates upgrade detection to the OTA upgrade detection service, the OTA upgrade detection service initiates a version information collection event to each SOA service, after the version information of each SOA service is collected, the cloud performs upgrade detection interaction with the cloud, the cloud performs version compatibility detection on the SOA service a based on the version information of each service, generates OTA upgrade information meeting the current service compatibility requirement, feeds back to the OTA upgrade detection service, and then performs OTA upgrade on the SOA service a based on the OTA upgrade information.
Specifically, when the current service is not compatible with the primary dependent service version, upgrade information capable of satisfying compatibility of the current service with the corresponding primary dependent service version is generated based on version information of the corresponding primary dependent service.
When the current service and the target service are not compatible with the common service version, upgrade information capable of meeting the compatibility of the current service and the target service with the common service version is generated based on the secondary dependent version information of the target service with the common service.
According to the invention, the SOA service sends the upgrade detection instruction and the version compatibility of the corresponding SOA service is detected based on the version information of each SOA service, so that the version compatibility detection of the SOA service can be realized, and the method is applicable to OTA security upgrade detection after SOA service is implemented, thereby improving the effectiveness of the version compatibility detection of the SOA service. Meanwhile, the version compatibility detection of the corresponding SOA service is realized by judging the version compatibility of the current service and the primary dependent service and the version compatibility of the current service and the target service for the common service, so that when a plurality of SOA services depend on the same SOA service and the dependent versions are inconsistent, the version compatibility among the plurality of SOA services can be effectively identified, and the comprehensiveness of the version compatibility detection of the SOA service can be improved.
In the implementation process, the configuration file comprises a predefined version dependent configuration; version dependent configurations include, but are not limited to, service name, version information, and dependent service information; the dependent service information includes, but is not limited to, the name of the dependent service, and the corresponding predefined dependent version rules. The dependency version rule specifies dependency version information or dependency version range information of the service for the corresponding dependency service. When the dependent versions of the two services are different or the interval of the dependent version range has a difference, the two service versions are judged to be incompatible.
The version-dependent configuration writing specification of a specific standard is the root of ensuring that version compatibility detection can function properly. By relying on version rules, enumerating version compatibility of each SOA service can be avoided, and storage space is saved. In particular, the method comprises the steps of,
The writing specification of the version-dependent configuration is predefined in the format as follows:
Wherein, the service represents the service name of the current SOA service, and the service name only allows combination by using numbers, letters and underlines; version indicates the version number of the current SOA service, following the naming convention of a.b.c format (A, B, C is digital); DEPENDENCIES denotes names of other SOA services on which the current SOA service depends and corresponding version-dependent rules.
Specifically, the dependency version rule of the present embodiment is shown in table 1.
TABLE 1
In order to better explain the technical scheme of the invention, the following two scenes are constructed in the embodiment.
Scene one, as shown in fig. 3:
Service a (current service) needs to rely on service B (≡1.2.3, meaning > =1.2.3 and < 2.0.0), service C (≡1.3.2, meaning > =1.3.2 and < 2.0.0), service D (≡ 1.5.4, meaning > = 1.5.4 and < 2.0.0). At this time, the service B, the service C, and the service D are primary dependent services of the service a.
Meanwhile, service D again needs to rely on service B (∈1.3.2, meaning > =1.3.2 and < 2.0.0). At this time, the service B is a secondary dependent service of the service D, and the service D is a target service and the service B is a common service.
Since the dependency version range (≡1.2.3, meaning > =1.2.3 and < 2.0.0) of service a (current service) on service B (common service) covers the dependency version range (≡1.3.2, meaning > =1.3.2 and < 2.0.0) of service D (target service) on service B (common service), there is no compatibility problem for the version of service a (current service) and service D (target service) on service B (common service), i.e. service a (current service) has version compatibility.
Scene two, as shown in fig. 4:
Service a (current service) needs to rely on service B (-1.2.3, representing > =1.2.3 and < 1.3.0), service C (-1.3.2, representing > =1.3.2 and < 2.0.0), service D (-1.5.4, representing > = 1.5.4 and < 2.0.0). At this time, the service B, the service C, and the service D are primary dependent services of the service a.
While at the same time. Service D in turn needs to rely on service B (∈1.3.2, meaning > =1.3.2 and < 2.0.0). At this time, the service B is a secondary dependent service of the service D, and the service D is a target service and the service B is a common service.
Since the dependency version range (≡1.2.3, meaning > =1.2.3 and < 1.3.0) of service a (current service) on service B (common service) conflicts with the dependency version range (≡1.3.2, meaning > =1.3.2 and < 2.0.0) of service D (target service) on service B (common service). For this reason, service a (current service) and service D (target service) have compatibility problems for versions of service B (common service), i.e., service a (current service) does not have version compatibility.
Embodiment two:
a readable storage medium is disclosed in this embodiment.
A readable storage medium having stored thereon a computer management class program which when executed by a processor implements the steps of the SOA-based, serviced OTA upgrade detection method of the present invention. The readable storage medium may be a device such as a usb disk or a computer having a readable storage function.
Finally, it should be noted that the above embodiments are only for illustrating the technical solution of the present invention and not for limiting the technical solution, and those skilled in the art should understand that modifications and equivalents may be made to the technical solution of the present invention without departing from the spirit and scope of the present invention, and all such modifications and equivalents are included in the scope of the claims.
Claims (7)
1. The OTA upgrade detection method based on SOA service is characterized by comprising the following steps:
s1: acquiring an upgrade detection instruction of a current service;
s2: version information of each service is obtained;
S3: detecting version compatibility of the current service based on the version information of each service, and generating corresponding upgrading information according to the version compatibility detection result;
in step S3, version compatibility detection is performed on the current service by:
s301: reading a configuration file of the current service, and analyzing to obtain primary dependent service information of the current service; the primary dependent service information comprises each primary dependent service and a corresponding primary dependent version;
302: reading configuration files of all primary dependent services, analyzing to obtain secondary dependent service information of all primary dependent services, and taking the primary dependent services with the secondary dependent service information as target services; the secondary dependent service information comprises each secondary dependent service and a corresponding secondary dependent version;
S303: determining whether the primary dependent version of the current service for each primary dependent service is version compatible with the version of the corresponding primary dependent service: if yes, executing S304; otherwise, the current service is not compatible with the primary dependent service version, and does not have version compatibility;
In step S303, when the current service is not compatible with the primary dependent service version, generating upgrade information capable of satisfying the compatibility between the current service and the corresponding primary dependent service version based on the version information of the corresponding primary dependent service;
S304: determining whether the same secondary dependent service and primary dependent service exist: if yes, the same secondary dependent service and primary dependent service are used as common services, and S305 is executed; otherwise, the current service has version compatibility;
in step S304, when the current service and the target service are not compatible with the common service version, generating upgrade information capable of meeting the compatibility of the current service and the target service with the common service version based on the secondary dependent version information of the target service with the common service;
S305: determining whether the current service and the target service are version compatible for the common service based on the primary dependent version of the current service for the common service and the secondary dependent version of the target service for the common service: if yes, the current service has version compatibility; otherwise, the current service does not have version compatibility;
S4: and upgrading the current service based on the corresponding upgrading information.
2. The SOA-based OTA upgrade detection method of claim 1 wherein: the configuration file includes a predefined version dependent configuration.
3. The SOA-based OTA upgrade detection method of claim 2 wherein: version dependent configurations include, but are not limited to, service name, version information, and dependent service information.
4. The SOA-based OTA upgrade detection method of claim 3 wherein: the dependent service information includes, but is not limited to, the name of the dependent service, and the corresponding predefined dependent version rules.
5. The SOA-based OTA upgrade detection method of claim 4 wherein: the dependency version rule specifies dependency version information or dependency version range information of the service for the corresponding dependency service.
6. The SOA-based OTA upgrade detection method of claim 5 wherein: when the dependent versions of the two services are different or the interval of the dependent version range has a difference, the two service versions are judged to be incompatible.
7. A readable storage medium having stored thereon a computer management class program which when executed by a processor implements the steps of the SOA based serviced OTA upgrade detection method according to any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210068216.6A CN114328270B (en) | 2022-01-20 | 2022-01-20 | OTA upgrade detection method based on SOA service and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210068216.6A CN114328270B (en) | 2022-01-20 | 2022-01-20 | OTA upgrade detection method based on SOA service and readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114328270A CN114328270A (en) | 2022-04-12 |
| CN114328270B true CN114328270B (en) | 2024-05-03 |
Family
ID=81029244
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210068216.6A Active CN114328270B (en) | 2022-01-20 | 2022-01-20 | OTA upgrade detection method based on SOA service and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114328270B (en) |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101957794A (en) * | 2010-09-21 | 2011-01-26 | 中国科学院软件研究所 | Deployment constraint automatic detection method for Web application |
| CN102253999A (en) * | 2011-07-12 | 2011-11-23 | 北京新媒传信科技有限公司 | Verification method for service dependency |
| CN107291457A (en) * | 2017-06-08 | 2017-10-24 | 重庆长安汽车股份有限公司 | The long-range renewal computing system and method for entire car controller software |
| CN111061643A (en) * | 2019-12-24 | 2020-04-24 | 五八同城信息技术有限公司 | SDK cluster compatibility detection method and device, electronic equipment and storage medium |
| CN111258614A (en) * | 2020-05-06 | 2020-06-09 | 深圳开源互联网安全技术有限公司 | Method, system, equipment and storage medium for detecting upgrade exception of project third-party library |
| CN111694592A (en) * | 2020-06-24 | 2020-09-22 | 深圳壹账通智能科技有限公司 | Management method and system for project version release |
| CN112214408A (en) * | 2020-10-12 | 2021-01-12 | 北京字节跳动网络技术有限公司 | Dependency conflict detection method and device, electronic equipment and computer readable medium |
| CN112328494A (en) * | 2020-11-26 | 2021-02-05 | 浪潮电子信息产业股份有限公司 | Compatibility detection method, device, equipment and readable storage medium |
| CN112559373A (en) * | 2020-12-24 | 2021-03-26 | 郑州信大捷安信息技术股份有限公司 | Software compatibility management method and system |
| CN113515297A (en) * | 2021-08-12 | 2021-10-19 | 深圳市晨北科技有限公司 | Version updating method and device, electronic equipment and storage medium |
| CN113688045A (en) * | 2021-08-26 | 2021-11-23 | 烽火通信科技股份有限公司 | Method and device for automatically checking compatibility of binary interface |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9430228B2 (en) * | 2013-12-16 | 2016-08-30 | International Business Machines Corporation | Verification of backward compatibility of software components |
| US10691577B2 (en) * | 2017-03-03 | 2020-06-23 | Snyk Limited | Identifying flawed dependencies in deployed applications |
-
2022
- 2022-01-20 CN CN202210068216.6A patent/CN114328270B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101957794A (en) * | 2010-09-21 | 2011-01-26 | 中国科学院软件研究所 | Deployment constraint automatic detection method for Web application |
| CN102253999A (en) * | 2011-07-12 | 2011-11-23 | 北京新媒传信科技有限公司 | Verification method for service dependency |
| CN107291457A (en) * | 2017-06-08 | 2017-10-24 | 重庆长安汽车股份有限公司 | The long-range renewal computing system and method for entire car controller software |
| CN111061643A (en) * | 2019-12-24 | 2020-04-24 | 五八同城信息技术有限公司 | SDK cluster compatibility detection method and device, electronic equipment and storage medium |
| CN111258614A (en) * | 2020-05-06 | 2020-06-09 | 深圳开源互联网安全技术有限公司 | Method, system, equipment and storage medium for detecting upgrade exception of project third-party library |
| CN111694592A (en) * | 2020-06-24 | 2020-09-22 | 深圳壹账通智能科技有限公司 | Management method and system for project version release |
| CN112214408A (en) * | 2020-10-12 | 2021-01-12 | 北京字节跳动网络技术有限公司 | Dependency conflict detection method and device, electronic equipment and computer readable medium |
| CN112328494A (en) * | 2020-11-26 | 2021-02-05 | 浪潮电子信息产业股份有限公司 | Compatibility detection method, device, equipment and readable storage medium |
| CN112559373A (en) * | 2020-12-24 | 2021-03-26 | 郑州信大捷安信息技术股份有限公司 | Software compatibility management method and system |
| CN113515297A (en) * | 2021-08-12 | 2021-10-19 | 深圳市晨北科技有限公司 | Version updating method and device, electronic equipment and storage medium |
| CN113688045A (en) * | 2021-08-26 | 2021-11-23 | 烽火通信科技股份有限公司 | Method and device for automatically checking compatibility of binary interface |
Non-Patent Citations (2)
| Title |
|---|
| Understanding and Detecting Fragmentation-Induced Compatibility Issues for Android Apps;Lili Wei等;《IEEE Transactions on Software Engineering》;20181016;第1176 - 1199页 * |
| 基于AC-DC开关电源系统的电磁兼容设计及稳定性研究;何惠森;《中国博士学位论文全文数据库信息科技辑》;20130515(第5期);I136-7 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114328270A (en) | 2022-04-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108804299B (en) | Application program exception handling method and device | |
| US20050038934A1 (en) | USB-based peripheral device and method for starting up the USB-based peripheral device | |
| RU2377634C2 (en) | Licensing program interface | |
| CN106055375B (en) | Application program installation method and device | |
| CN111061643B (en) | SDK cluster compatibility detection method and device, electronic equipment and storage medium | |
| CN111596967A (en) | Application function configuration method, terminal device, server and storage medium | |
| CN111967017A (en) | Method and device for generating dependency relationship, terminal equipment and storage medium | |
| CN112052030A (en) | Interface authority configuration method, storage medium and system of vehicle-mounted application program | |
| CN114328270B (en) | OTA upgrade detection method based on SOA service and readable storage medium | |
| CN112632474B (en) | Vehicle-mounted machine software and hardware activation method | |
| CN112256351B (en) | Method for realizing Feign component, method and device for calling micro-service | |
| CN115935321B (en) | Method, device and storage medium for accessing algorithm library | |
| CN107977313B (en) | Debugging interface calling method and device | |
| CN113791824B (en) | Peripheral driver loading method, system and medium of terminal equipment | |
| CN113590179B (en) | Plug-in detection method and device, electronic equipment and storage medium | |
| CN115695400A (en) | Method and terminal for interaction between Web page and local application | |
| CN113282906B (en) | Authority detection method, device, terminal and storage medium | |
| CN114115933A (en) | Method, system, device, electronic equipment and medium for software upgrading | |
| CN112817522A (en) | Data storage method and device, electronic equipment and storage medium | |
| CN109165023B (en) | Method, device and equipment for modifying ISO (International organization for standardization) mirror image file | |
| CN114490010A (en) | Resource operation control method, electronic device, chip and readable storage medium | |
| CN111459608A (en) | Application system deployment method and device, computer equipment and storage medium | |
| CN111339173A (en) | Data sharing method, server and readable storage medium | |
| CN116881880B (en) | Space-time data management system and space-time data service resource cooperative scheduling method | |
| CN111475226B (en) | Electronic device, micro-service calling method, and computer-readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |