CN114328270A - OTA upgrade detection method based on SOA (service oriented architecture) service and readable storage medium - Google Patents
OTA upgrade detection method based on SOA (service oriented architecture) service and readable storage medium Download PDFInfo
- Publication number
- CN114328270A CN114328270A CN202210068216.6A CN202210068216A CN114328270A CN 114328270 A CN114328270 A CN 114328270A CN 202210068216 A CN202210068216 A CN 202210068216A CN 114328270 A CN114328270 A CN 114328270A
- Authority
- CN
- China
- Prior art keywords
- service
- version
- dependent
- soa
- information
- 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.)
- Granted
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 68
- 230000001419 dependent effect Effects 0.000 claims description 132
- 238000000034 method Methods 0.000 abstract description 13
- 230000008569 process Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Abstract
The invention relates to the technical field of SOA (service oriented architecture) servitization, in particular to an OTA (over-the-air) upgrade detection method and a readable storage medium based on SOA servitization. The method comprises the following steps: acquiring an upgrade detection instruction of a current service; acquiring version information of each service; performing version compatibility detection on 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 validity and comprehensiveness of the compatibility detection of the SOA service version can be considered.
Description
Technical Field
The invention relates to the technical field of SOA (service oriented architecture) servitization, in particular to an OTA (over-the-air) upgrade detection method and a readable storage medium based on SOA servitization.
Background
Software defined automotive has become an industry consensus, and software architectures have begun to be Service-oriented architecture (SOA) designs based on digital, intelligent requirements. Each domain (vehicle control, cockpit, electronic and electrical equipment architecture and the like) of the automobile provides own capability in an SOA service mode to generate SOA services, each SOA service can be randomly used under the permission of authority, the condition that one SOA service operates based on other SOA services is called as service dependence, and the corresponding service which is depended on is called as dependent service.
Based on the above, version compatibility detection between SOA services of respective domains becomes particularly important. Therefore, Chinese patent with publication number CN111562935B discloses an OTA security upgrade system and an upgrade method thereof, wherein the OTA platform upgrade method comprises security upgrade management, security version management, version download management and security control; the OTA terminal upgrading method is matched with the OTA platform function, and provides functions of acquiring and processing a corresponding upgrading version file key, judging and preordering upgrading preconditions, managing safety key requests and detecting rules of upgrading process states for upgrading of each intelligent part device, and the OTA terminal is integrated to manage upgrading operations of a plurality of intelligent parts.
The OTA upgrading method in the prior scheme realizes the safe upgrading of the multi-type intelligent part OTA through the management of the standardized equipment upgrading process. 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 is performed, so that the validity of SOA service version compatibility detection is poor. Meanwhile, in actual application, the situations that a plurality of SOA services depend on the same SOA service and the dependent versions of the SOA services on the same dependent service are inconsistent exist, and at the moment, the version compatibility among the plurality of SOA services needs to be detected so as to ensure the comprehensiveness of the detection of the SOA service version compatibility. Therefore, how to design a method suitable for OTA upgrade detection after SOA servitization is an urgent technical problem to be solved.
Disclosure of Invention
Aiming at the defects of the prior art, the technical problems to be solved by the invention are as follows: the OTA upgrade detection method based on SOA service can be suitable for OTA upgrade detection after SOA service, thereby giving consideration to the effectiveness and comprehensiveness of the compatibility detection of the SOA service version.
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: acquiring version information of each service;
s3: performing version compatibility detection on 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, the version compatibility detection is performed on the current service through 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 the configuration file of each primary dependent service, analyzing to obtain secondary dependent service information of each primary dependent service, and taking the primary dependent service with the secondary dependent service information as a target service; the secondary dependent service information comprises each secondary dependent service and a corresponding secondary dependent version;
s303: judging whether the primary dependent version of the current service for each primary dependent service is compatible with the version of the corresponding primary dependent service: if yes, go to S304; otherwise, the current service is incompatible 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 so, the same secondary dependent service and primary dependent service are taken as a common service, 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, the upgrade information that can satisfy the compatibility between the current service and the corresponding primary dependent service version is generated based on the version information of the corresponding primary dependent service.
Preferably, in step S304, when the current service and the target service are incompatible with the common service version, upgrade information that can satisfy 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 respect to the common service.
Preferably, the configuration file comprises a predefined version-dependent configuration.
Preferably, the version dependent configuration includes, but is not limited to, a service name, version information, and dependent service information.
Preferably, the dependent service information includes, but is not limited to, a name of the dependent service, and a corresponding predefined dependent version rule.
Preferably, the dependent version rule specifies dependent version information or dependent version range information of the service for the corresponding dependent service.
Preferably, when the dependent versions of the two services are different or there is a difference between the intervals of the dependent version ranges, it is determined that the two service versions are incompatible.
The invention also discloses a readable storage medium, on which a computer management program is stored, and the computer management program realizes the steps of the OTA upgrade detection method based on SOA service 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:
the invention can realize the version compatibility detection of the SOA service by sending the upgrade detection instruction by the SOA service and detecting the version compatibility of the corresponding SOA service based on the version information of each SOA service, and can be suitable for the OTA safety upgrade detection after the SOA service, 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 to the common service, so that the version compatibility among a plurality of SOA services can be effectively identified when the plurality of SOA services depend on the same SOA service and the dependent versions are inconsistent, and the comprehensiveness of the SOA service version compatibility detection can be improved.
Drawings
For purposes of promoting a better understanding of the objects, aspects and advantages of the invention, reference will now be made in detail to the present invention as illustrated in the accompanying drawings, in which:
FIG. 1 is a logic block diagram of an OTA upgrade detection method based on SOA services;
FIG. 2 is a main flow chart of an OTA upgrade detection method based on SOA services;
FIG. 3 is a diagram of a scenario one;
fig. 4 is a schematic diagram of a scene two.
Detailed Description
The following is further detailed by the specific embodiments:
the first embodiment is as follows:
the embodiment discloses an OTA upgrade detection method based on SOA service.
As shown in fig. 1, the SOA-based OTA upgrade detection method includes 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 upgrade information according to the version compatibility detection result;
s4: performing (OTA) upgrade on a current (SOA) service based on the corresponding upgrade information.
Specifically, the version compatibility detection is performed on the current service through 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 the configuration file of each primary dependent service, analyzing to obtain secondary dependent service information of each primary dependent service, and taking the primary dependent service with the secondary dependent service information as a target service; the secondary dependent service information comprises each secondary dependent service and a corresponding secondary dependent version;
s303: judging whether the primary dependent version of the current service for each primary dependent service is compatible with the version of the corresponding primary dependent service: if yes, go to S304; otherwise, the current service is incompatible 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 so, the same secondary dependent service and primary dependent service are taken as a common service, 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 SOA-based OTA upgrade detection method of the present invention can generate corresponding software code or software service in a program programming manner, and can further be run and implemented on a server and a computer.
Specifically, as shown in fig. 2, in this embodiment, when the vehicle is started (for example, an upgrade detection program may be initiated by another trigger mechanism), the SOA service a initiates upgrade detection for the OTA upgrade detection service, the OTA upgrade detection service may initiate a version information collection event for each SOA service, after the version information of each SOA service is collected, the SOA service a is uniformly upgraded and detected 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, and feeds the OTA upgrade information back to the OTA upgrade detection service, and then the SOA service a is subjected to OTA upgrade by the OTA upgrade detection service based on the OTA upgrade information.
Specifically, when the current service is not compatible with the primary dependent service version, the upgrade information that can satisfy the compatibility between the current service and the corresponding primary dependent service version is generated based on the version information of the corresponding primary dependent service.
When the current service and the target service are incompatible 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.
The invention can realize the version compatibility detection of the SOA service by sending the upgrade detection instruction by the SOA service and detecting the version compatibility of the corresponding SOA service based on the version information of each SOA service, and can be suitable for the OTA safety upgrade detection after the SOA service, 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 to the common service, so that the version compatibility among a plurality of SOA services can be effectively identified when the plurality of SOA services depend on the same SOA service and the dependent versions are inconsistent, and the comprehensiveness of the SOA service version compatibility detection can be improved.
In the specific implementation process, the configuration file comprises a predefined version dependent configuration; version dependent configurations include, but are not limited to, service names, 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 dependent version rule specifies dependent version information or dependent version range information of the service for the corresponding dependent service. And when the dependent versions of the two services are different or a difference set exists between the intervals of the dependent version ranges, judging that the two service versions are not compatible.
The specific standard's version-dependent configuration writing specification is essential to ensure that the version compatibility check is able to function properly. By depending on the version rules, the version compatibility of each SOA service can be prevented from being enumerated, and further the storage space is saved. In particular, the method comprises the following steps of,
the written specification of the version dependent configuration defines a predefined format as follows:
the service represents the service name of the current SOA service, and the service name only allows the combination of numbers, letters and underlines; version indicates the version number of the current SOA service, following the naming specification in the a.b.c format (A, B, C are numbers); the dependencies indicate names of other SOA services that the current SOA service depends on and corresponding rules on which the version depends.
Specifically, the version-dependent rule of the present embodiment is shown in table 1.
TABLE 1
In order to better explain the technical solution of the present invention, the following two scenarios are constructed in this embodiment.
Scenario one, as shown in fig. 3:
service a (the 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, service B, service C, and service D are primary dependent services of service a.
Meanwhile, service D needs to depend on service B (^1.3.2, meaning > < 1.3.2 and < 2.0.0). At this time, service B is a secondary dependent service of service D, and service D is a target service and service B is a common service.
Since the dependent version range (^1.2.3, where > is 1.2.3 and <2.0.0) of the service a (current service) to the service B (common service) covers the dependent version range (^1.3.2, where > is 1.3.2 and <2.0.0) of the service D (target service) to the service B (common service), there is no compatibility problem for the versions of the service a (current service) and the service D (target service), that is, the service a (current service) has version compatibility.
Scenario two, as shown in fig. 4:
service a (the current service) needs to depend on service B (-1.2.3, meaning > < 1.2.3 and <1.3.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, service B, service C, and service D are primary dependent services of service a.
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, service B is a secondary dependent service of service D, and service D is a target service and service B is a common service.
A conflict arises due to the dependent version range (^1.2.3, meaning > < 1.2.3 and <1.3.0) of service a (current service) to service B (common service) and the dependent version range (^1.3.2, meaning > < 1.3.2 and <2.0.0) of service D (target service) to service B (common service). For this reason, there is a compatibility problem between service a (current service) and service D (target service) with respect to the version of service B (common service), that is, service a (current service) does not have version compatibility.
Example two:
disclosed in the present embodiment is a readable storage medium.
A readable storage medium, on which a computer management class program is stored, which when executed by a processor implements the steps of the SOA servitization-based OTA upgrade detection method of the present invention. The readable storage medium can be a device with readable storage function such as a U disk or a computer.
Finally, it should be noted that the above embodiments are only used for illustrating the technical solutions of the present invention and not for limiting the technical solutions, and those skilled in the art should understand that modifications or equivalent substitutions can be made on the technical solutions of the present invention without departing from the spirit and scope of the technical solutions, and all that should be covered by the claims of the present invention.
Claims (10)
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: acquiring version information of each service;
s3: performing version compatibility detection on 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.
2. The SOA-servization-based OTA upgrade detection method according to claim 1, wherein in step S3, the 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 the configuration file of each primary dependent service, analyzing to obtain secondary dependent service information of each primary dependent service, and taking the primary dependent service with the secondary dependent service information as a target service; the secondary dependent service information comprises each secondary dependent service and a corresponding secondary dependent version;
s303: judging whether the primary dependent version of the current service for each primary dependent service is compatible with the version of the corresponding primary dependent service: if yes, go to S304; otherwise, the current service is incompatible 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 so, the same secondary dependent service and primary dependent service are taken as a common service, 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.
3. The SOA-servization-based OTA upgrade detection method according to claim 2, wherein: in step S303, when the current service is not compatible with the primary dependent service version, upgrade information that can satisfy the compatibility between the current service and the corresponding primary dependent service version is generated based on the version information of the corresponding primary dependent service.
4. The SOA-servization-based OTA upgrade detection method according to claim 2, wherein: in step S304, when the current service and the target service are incompatible with the common service version, upgrade information that can satisfy 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 respect to the common service.
5. The SOA-servization-based OTA upgrade detection method according to claim 2, wherein: the configuration file includes a predefined version-dependent configuration.
6. The SOA-servization-based OTA upgrade detection method according to claim 5, wherein: version dependent configurations include, but are not limited to, service names, version information, and dependent service information.
7. The SOA-servization-based OTA upgrade detection method according to claim 6, wherein: the dependent service information includes, but is not limited to, the name of the dependent service, and the corresponding predefined dependent version rules.
8. The SOA-servization-based OTA upgrade detection method according to claim 7, wherein: the dependent version rule specifies dependent version information or dependent version range information of the service for the corresponding dependent service.
9. The SOA-servization-based OTA upgrade detection method according to claim 8, wherein: and when the dependent versions of the two services are different or a difference set exists between the intervals of the dependent version ranges, judging that the two service versions are not compatible.
10. A readable storage medium, on which a computer management class program is stored, which when executed by a processor implements the steps of the SOA services based OTA upgrade detection method according to any of the claims 1-9.
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 true CN114328270A (en) | 2022-04-12 |
| CN114328270B 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 (13)
| 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 |
| US20150169320A1 (en) * | 2013-12-16 | 2015-06-18 | International Business Machines Corporation | Verification of backward compatibility of software components |
| CN107291457A (en) * | 2017-06-08 | 2017-10-24 | 重庆长安汽车股份有限公司 | The long-range renewal computing system and method for entire car controller software |
| US20180260301A1 (en) * | 2017-03-03 | 2018-09-13 | Snyk Limited | Identifying flawed dependencies in deployed applications |
| 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 |
-
2022
- 2022-01-20 CN CN202210068216.6A patent/CN114328270B/en active Active
Patent Citations (13)
| 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 |
| US20150169320A1 (en) * | 2013-12-16 | 2015-06-18 | International Business Machines Corporation | Verification of backward compatibility of software components |
| US20180260301A1 (en) * | 2017-03-03 | 2018-09-13 | Snyk Limited | Identifying flawed dependencies in deployed applications |
| 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 |
|---|
| LILI WEI等: "Understanding and Detecting Fragmentation-Induced Compatibility Issues for Android Apps", 《IEEE TRANSACTIONS ON SOFTWARE ENGINEERING》, 16 October 2018 (2018-10-16), pages 1176, XP011819374, DOI: 10.1109/TSE.2018.2876439 * |
| 何惠森: "基于AC-DC开关电源系统的电磁兼容设计及稳定性研究", 《中国博士学位论文全文数据库信息科技辑》, no. 5, 15 May 2013 (2013-05-15), pages 136 - 7 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114328270B (en) | 2024-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2377634C2 (en) | Licensing program interface | |
| US9679130B2 (en) | Pervasive package identifiers | |
| US20030023770A1 (en) | Automated software driver installation | |
| US9021055B2 (en) | Nonconforming web service policy functions | |
| CN108763951B (en) | Data protection method and device | |
| CN114564158A (en) | Method, device, equipment and medium for controlling document printing under Linux system | |
| US10511631B2 (en) | Safe data access through any data channel | |
| CN114328270A (en) | OTA upgrade detection method based on SOA (service oriented architecture) service and readable storage medium | |
| CN108647516B (en) | Method and device for defending against illegal privilege escalation | |
| CN111538566A (en) | Mirror image file processing method, device and system, electronic equipment and storage medium | |
| CN111222122A (en) | Application authority management method and device and embedded equipment | |
| CN115712918A (en) | File protection method based on Linux system and electronic equipment | |
| CN116340092A (en) | Security monitoring method, device, equipment and medium for software development kit | |
| CN114115933A (en) | Method, system, device, electronic equipment and medium for software upgrading | |
| CN113282906B (en) | Authority detection method, device, terminal and storage medium | |
| CN109597662B (en) | Method and device for calling non-public library in mobile terminal and electronic equipment | |
| CN114490010A (en) | Resource operation control method, electronic device, chip and readable storage medium | |
| EP3608816A1 (en) | Processing system and method of executing functions | |
| EP3070610A1 (en) | Information processing device, control method thereof, and recording medium | |
| CN109918895B (en) | Method, electronic device, and computer-readable medium for outputting data | |
| CN111611555B (en) | Physical layer authorization and access method and device | |
| CN117436069A (en) | Authority verification method, device, equipment and medium for user process | |
| CN115563594A (en) | User identifier acquisition method and device, electronic equipment and storage medium | |
| CN117632188A (en) | Version package updating method, device, equipment and readable storage medium | |
| CN117171732A (en) | Method and device for realizing process protection of user layer, storage medium and electronic equipment |
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 |