CN116795435A

CN116795435A - Compatibility management and control method and related equipment

Info

Publication number: CN116795435A
Application number: CN202210261901.0A
Authority: CN
Inventors: 万承臻; 余涛; 裴太乙; 刘勋; 张勇智; 瞿时万
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-03-15
Filing date: 2022-03-15
Publication date: 2023-09-22

Abstract

The application discloses a compatibility management and control method and related equipment, which can judge whether an application can be installed and operated on equipment or not based on a product compatibility identifier PCID and a product compatibility identifier RPCID after the OS is flexibly deployed to the equipment under the condition that the aim of supporting all types of equipment by using a unified OS is fulfilled, and if so, the application can be distributed to the equipment, so that the problem of compatibility between the equipment and the application can be solved.

Description

Compatibility management and control method and related equipment

Technical Field

The present application relates to the field of terminal technologies, and in particular, to a compatibility management and control method and related devices.

Background

In the age of everything interconnection today, the development of intelligent terminal devices has entered into a fast lane, the types of devices are becoming more and more abundant, and in order to enable a set of operating systems (OperatingSystem, OS) to support all types of devices, better assemblability of the OS is necessarily required.

One method for improving the assemblability of the OS is to uniformly configure the OS, however, at present, different types of devices generally correspond to different OS, so that uniform configuration of the OS cannot be realized, and an application developer needs to perform differentiated application development according to different OS when developing an application, so that flexibility is poor.

Disclosure of Invention

The embodiment of the application provides a compatibility management and control method and related equipment, which can solve the problem of compatibility between equipment and application.

In a first aspect, an embodiment of the present application provides a communication system, where the communication system includes a development platform, an application distribution platform, and a user device, where: the development platform is used for: acquiring one or more components and generating a first identification based on the one or more components; the first identifier is used for indicating a first device system capability SysCap set, and the first device SysCap set is a SysCap set of an operating system of the user equipment; acquiring a second identifier; the second identifier is used for indicating a first application SysCap set, wherein the first application SysCap set is a SysCap set required by the first application when installed and operated on the user equipment; the application distribution platform is used for: receiving a second identifier sent by the development platform; acquiring a first identifier; in the case that the first device SysCap set comprises the first application SysCap set based on the first identifier and the second identifier, sending a first request to the user device, wherein the first request is used for indicating the user device to install the first application; the user equipment is used for: the first application is installed.

By providing the compatibility management and control method, under the condition that the aim of supporting all types of equipment by using a unified OS is achieved, after the OS is flexibly deployed to the equipment, whether the application can be installed and operated on the equipment or not can be judged based on the PCID of the product compatibility identifier and the RPCID of the product compatibility identifier, if so, the application can be distributed to the equipment, and therefore the problem of compatibility between the equipment and the application can be solved.

In one possible implementation, the first identifier is a first product compatibility identifier PCID and the second identifier is a first required product compatibility identifier RPCID.

In this way, the application distribution platform may determine, based on the first PCID and the first RPCID, whether the first device SysCap set includes the first application SysCap set, if so, send the first request to the user device, and if not, not send the first request to the user device.

In one possible implementation, the communication system further includes a device authentication platform for: receiving and storing a first identifier sent by a development platform; the first identification is sent to the application distribution platform.

Thus, the device authentication platform can perform device authentication based on the first identification; the first identification may also be sent to the application distribution platform so that the application distribution platform generates the first device SysCap set based on the first identification.

In a second aspect, an embodiment of the present application provides a compatibility management and control method, applied to an application distribution platform, where the method includes: the method comprises the steps that an application distribution platform obtains a first identifier, wherein the first identifier is used for indicating a first device system capability SysCap set, and the first device SysCap set is a SysCap set of an operating system of user equipment; the application distribution platform acquires a second identifier, wherein the second identifier is used for indicating a first application SysCap set, and the first application SysCap set is a SysCap set required by the first application when being installed and operated on the user equipment; the application distribution platform sends a first request to the user equipment, wherein the first request is used for indicating the user equipment to install the first application, under the condition that the first device SysCap set comprises the first application SysCap set based on the first identifier and the second identifier.

The embodiment of the application provides a compatibility management and control method, and an application distribution platform can judge whether an application can be installed and operated on equipment or not based on a product compatibility identifier PCID and a product compatibility identifier RPCID, if so, the application can be distributed to the equipment, so that the problem of compatibility between the equipment and the application can be solved.

In one possible implementation manner, the application distribution platform obtains the first identifier, which specifically includes: the application distribution platform acquires a first PCID from the device authentication platform; the first PCID is generated by the development platform based on the first device SysCap set and is sent to the device authentication platform.

In this way, the application distribution platform may generate a first device SysCap set based on the first PCID.

In one possible implementation manner, the application distribution platform obtains the second identifier, which specifically includes: the application distribution platform receives a first RPCID sent by the development platform; the first RPCID is generated by the development platform based on a first application SysCap set, and the first application SysCap set is generated by the application distribution platform based on a first SDK or a first PCID issued by the software development kit SDK issuing platform.

In this way, the application distribution platform may generate a first set of application SysCap based on the first RPCID.

In a third aspect, an embodiment of the present application provides a compatibility management and control method, which is applied to a development platform, and is characterized in that the method includes: the development platform acquires first information, wherein the first information comprises a first Software Development Kit (SDK) or a first identifier, the first identifier is used for indicating a first device system capability (SysCap) set, and the first device SysCap set is a SysCap set of an operating system of user equipment; the development platform generates a second identifier based on the first information, wherein the second identifier is used for indicating a first application SysCap set, and the first application SysCap set is a SysCap set required by the first application when being installed and operated on the user equipment; the development platform sends the second identification to the application distribution platform.

In one possible implementation manner, the development platform generates the second identifier based on the first information, and specifically includes: under the condition that the equipment type of the user equipment is a first type, the development platform generates a first RPCID based on a first SDK; or, in the case that the device type of the user device is not the first type, the development platform generates the first RPCID based on the first PCID.

Thus, in the case where the user device is a first type of device (e.g., some of the exploded electronic devices such as a cell phone, a smart screen, a PC, a tablet, etc.), the development platform may generate the RPCID based on the SDK, and in the case where the user device is not a first type of device, the development platform may generate the RPCID based on the PCID.

In one possible implementation, before the development platform obtains the first information, the method further includes: the development platform obtains one or more components and generates a first identification based on the one or more components.

In this way, the development platform may obtain one or more components from the operating system development platform to assemble, form an operating system, generate a device SysCap set based on the one or more components, and encode the device SysCap set to generate the PCID.

In one possible implementation manner, the development platform generates a first identifier based on one or more components, specifically including: the development platform generates a first device SysCap set based on the one or more components; the development platform encodes the first device SysCap set to generate a first PCID.

In one possible implementation, after the development platform generates the first identification based on the one or more components, the method further includes: the development platform sends a second request to the equipment authentication platform, wherein the second request comprises the first PCID; and under the condition that the device authentication platform confirms that the device authentication passes based on the first PCID, the development platform receives and stores a first Token sent by the device authentication platform.

Therefore, the development platform can send the equipment authentication request to the equipment authentication platform, and after the equipment authentication is passed, the Token sent by the equipment authentication platform can be received, so that the safety is improved.

In a fourth aspect, an embodiment of the present application provides a compatibility management and control method, applied to a user equipment, where the method includes: the user equipment receives a first request sent by an application distribution platform, wherein the first request comprises a first Required Product Compatibility Identifier (RPCID); the method comprises the steps that under the condition that the user equipment determines that a first device SysCap set comprises a first application SysCap set based on a first RPCID and a first product compatibility identifier PCID, the user equipment installs a first application; the first PCID is used for indicating a first application SysCap set, the first application SysCap set is a SysCap set required by the first application when being installed and operated on the user equipment, the first PCID is used for indicating a first equipment system capability SysCap set, and the first equipment SysCap set is a SysCap set of an operating system of the user equipment.

In one possible implementation manner, the user equipment includes an application package management service PMS and a Samgr component, and the user equipment determines that the first device SysCap set includes a first application SysCap set based on the first RPCID and the first product compatibility identifier PCID, and specifically includes: the user equipment decodes the first RPCID by using the PMS to generate a first application SysCap set; the user equipment queries a first equipment SysCap set by utilizing the Samgr component; the user device determines, using the PMS, that the first device SysCap set includes a first application SysCap set.

In this way, before the user device installs and runs the application, it may first determine whether the first device SysCap set includes the first application SysCap set, and if so, install the application again.

In one possible implementation, before the user equipment installs the first application, the method further includes: the user equipment displays a first user interface, wherein the first user interface comprises a first option, and the first option is an option for installing a first application; the user device detects an operation of the user with respect to the first option.

In this way, the user device may display an application that can be installed, which is reinstalled by the user device if the user agrees to install.

In a fifth aspect, an embodiment of the present application provides a compatibility management and control method, applied to an equipment authentication platform, where the method includes: the equipment authentication platform receives a second request sent by the development platform, wherein the second request comprises a first product compatibility identifier PCID; the device authentication platform confirms that the device authentication passes based on the first PCID, generates a first Token, and stores the mapping relation between the first PCID and the first Token; the device authentication platform sends a first Token to the development platform.

In one possible implementation, after the device authentication platform sends the first Token to the development platform, the method further includes: the equipment authentication platform receives a third request sent by the application distribution platform; the device authentication platform sends the first PCID to the application distribution platform based on the third request.

In a sixth aspect, embodiments of the present application provide an electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories being operable to store computer program code comprising computer instructions that, when executed by the one or more processors, cause the electronic device to perform the method of the second or third aspect or any of the possible implementations of the fourth or fifth aspect described above.

In a seventh aspect, embodiments of the present application provide a computer storage medium storing a computer program comprising program instructions which, when run on an electronic device, cause the electronic device to perform the method of the second or third aspect or any of the possible implementations of the fourth or fifth aspect described above.

In an eighth aspect, embodiments of the present application provide a computer program product which, when run on a computer, causes the computer to perform the method of the second or third aspect or any of the possible implementations of the fourth or fifth aspect described above.

Drawings

FIG. 1 is a schematic diagram of a software architecture according to an embodiment of the present application;

fig. 2 is a schematic diagram of a communication system according to an embodiment of the present application;

FIG. 3 is a schematic diagram of normalized SDK generated based on operating system source code provided by an embodiment of the present application;

fig. 4 is a schematic structural diagram of a PCID of a product compatibility identifier according to an embodiment of the present application;

fig. 5A-5C are schematic diagrams of a component set included in a group of user equipments according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of an RPCID requiring product compatibility identification according to an embodiment of the present application;

FIG. 7 is a flow chart of a method for controlling compatibility according to an embodiment of the present application;

FIG. 8 is a schematic flow chart of an application development platform for generating RPCID of an application according to an embodiment of the present application;

fig. 9 is a schematic flow chart of application installation performed by a user equipment according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a SysCap registration and query process performed by a Samgr component in a user device according to an embodiment of the present application;

FIGS. 11A-11D are a set of user interface diagrams provided by an implementation of the present application;

fig. 12 is a schematic software structure of a user device according to an embodiment of the present application;

Fig. 13 is a schematic structural diagram of a user equipment according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Wherein, in the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: the three cases where a exists alone, a and B exist together, and B exists alone, and furthermore, in the description of the embodiments of the present application, "plural" means two or more than two.

It should be understood that the terms first, second, and the like in the description and in the claims and drawings are used for distinguishing between different objects and not necessarily for describing a particular sequential or chronological order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the described embodiments of the application may be combined with other embodiments.

For ease of understanding, some of the related concepts involved in embodiments of the application are described below.

1. Product compatibility label (ProductCompatibilityID, PCID)

PCID, which may also be referred to as a device compatibility identifier or a device system capability identifier, is used to flag the underlying system type (SystemType) and optional system capabilities (SystemCapability, sysCap) supported by the device.

The system types may include, but are not limited to, lightweight systems (e.g., connection type modules, sensor devices, wearable type devices, etc. in the smart home field), small systems (e.g., routers, electronic cat eyes, automobile recorders, etc. in the smart home field), standard systems (e.g., internet of things devices with screens, etc.), large systems (e.g., smart screens, smart phones, etc.).

Where system capabilities may refer to features or functions possessed by the operating system of the device, the system capabilities of the device may be provided by a collection of components that make up the operating system of the device.

In an embodiment of the present application, the PCID may be generated by encoding API version information (apieversion), a system type, a device vendor ID (ManufactureID, MID), and a set of components that make up the operating system of the device. Reference may be made specifically to the relevant content of the following embodiments, which are not developed here.

2. Required product compatibility identification (RequiredProductCompatibilityID, RPCID)

The RPCID, which may also be referred to as an application compatibility identifier, is used to flag the system capabilities that an application statically depends on, i.e., the set of system capabilities that the application requires.

In the embodiment of the application, the RPCID may be generated by encoding API version information (apipercent), and a set of system capabilities required by an application, where the set of system capabilities required by the application may refer to a set of components required by an operating system of a device to install and run the application. Reference may be made specifically to the relevant content of the following embodiments, which are not developed here.

3. Southbound interface, northbound interface

The southbound interface (Southbound Interface) is a downward pointing interface, i.e., a high level connection low level interface. In an embodiment of the present application, the southbound interface may be an interface provided by a device, that is, southbound may be for a device.

The northbound interface (Northbound Interface) is an upward pointing interface, i.e. a low level connection high level interface. In an embodiment of the present application, the northbound interface may be an interface provided by an application, that is, northbound may be specific to the application.

The north-south ecological compatibility of the operating system (OperatingSystem, OS) directly determines the ecological health of an operating system, and the problem of solving the ecological compatibility is the basis of success of the operating system.

Currently, equipment manufacturers (i.e., southbound developers) generally correspond to different OSs with equipment of different equipment types (Device types), and application developers (i.e., northbound developers) perform differentiated application development according to different OSs when developing applications, so that southbound and northbound ecological compatibility is ensured.

Taking an Android operating system as an example, android develops different OSs for devices of different device types, for example, android used for Phone/Pad is developed; androidTV was developed for use with TV; androidWear was developed for use with Wear equipment; android thongs used for IoT devices were developed; the Chrome OS for PC used for PC was developed; android Automative was developed for automotive use; etc. To support the use scenario of a specific device type, some additional interfaces are typically provided on the Android common platform, as shown in fig. 1, android Automative is to superimpose an automotive application programming interface (Car Application Programming Interface, car API) on the Android common platform.

Similar to Android, apple also developed different OS for different device types of devices, for example, IOS for Phone; developing an Ipad OS for Pad use; the Watch OS was developed for use with the Wear device; a Mac OS used for a PC was developed; etc.

With the continuous development of terminal technology, the device types of terminal devices are more and more, device type definitions are required to be continuously added, if a set of OS is developed for each device type of device, the problem of insufficient expandability of application distribution based on the device type is easily caused, and if the devices of the same device type have differences in device capabilities, application developers need to perform application differentiated distribution when developing applications, so that flexibility is poor.

Therefore, how to improve the assemblability of the OS, to support devices of all device types (i.e., to uniformly configure the OS) using a uniform OS, and to ensure the compatibility of the operating system in the north-south direction is a problem to be solved.

The embodiment of the application provides a compatibility management and control method based on PCID and RPCID, which can solve the problem of compatibility between equipment and application after the OS is flexibly deployed to the equipment under the condition that the aim of supporting all types of equipment by using a unified OS is fulfilled, namely, the compatibility of the north-south ecology can be ensured.

The following embodiments will describe specific implementation methods in detail, and are not described herein.

The following describes a communication system provided by an embodiment of the present application.

Fig. 2 illustrates a communication system provided by an embodiment of the present application.

As shown in fig. 2, the communication system may include an operating system development platform 201, a software development kit (SoftwareDevelopmentKit, SDK) release platform 202, a device development platform 203, a device authentication platform 204, an application development platform 205, an application distribution platform 206, and a user device 200. Wherein:

the operating system development platform 201 may be used to develop an operating system and provide operating system source code.

The operating system source code may include a set of mandatory components and a set of optional components, and the system capabilities that the components may provide may be defined as SysCap.

Wherein the set of mandatory parts may include one or more mandatory parts, such as part a (which may also be referred to as SysCapA) and the like; the set of optional components may include one or more optional components, such as component B (which may also be referred to as SysCapB), and the like.

In the embodiment of the present application, the os source code may refer to the hong os (harmyos) source code provided by OpenHarmony.

The software development kit publishing platform 202 (which may also be referred to as an SDK subsystem) may be used to generate a normalized SDK based on a set of operating system source code.

In an embodiment of the present application, the software development kit publishing platform 202 may generate and publish the normalized SDK based on the operating system source code provided by the operating system development platform 201, thereby satisfying the application development of multiple devices.

As shown in FIG. 3, the normalized SDK is generated based on operating system source code provided by the operating system development platform 201. In the embodiment of the present application, the normalized SDK generated by the software development kit publishing platform 202 may provide two functions in addition to compiling a tool chain, runtime (Run Time), development tool, and application programming interface (ApplicationProgrammingInterface, API) documents:

1. the SysCap attribute can be added in the API of each component, and the attribute is added for the API when the SDK is generated, so that the association between the API and the system capability can be realized, and the system capability which is depended on when the application is run can be required according to the SysCap attribute corresponding to the called API when the application is developed.

With continued reference to fig. 3, adding the SysCap attribute to the API may specifically be marking "@ SysCap" in the API. For example, API-1 is associated with part A, then "@ SysCapA" may be noted in API-1, i.e., API-1@ SysCapA; for another example, where API-2 is associated with part C, then "@ SysCapC" may be noted in API-2, i.e., API-2@SysCapC; for another example, API-3 is associated with part B, then "@ SysCapB", i.e., API-3@SysCapB, may be noted in API-3; etc.

2. A syshap set of corresponding device types for the payoff electronic device may be defined.

With continued reference to fig. 3, the corresponding device types of the explosive electronic device may include, but are not limited to, the following: cell phones, PCs, child watches, TVs, tablets.

Illustratively, as shown in fig. 3, the sysacap set corresponding to the mobile phone may be { SysCapA, sysCapB, …, sysacapx }; the SysCap set corresponding to PC may be { SysCapA, sysCapD, …, sysCapY }; the SysCap set corresponding to the child table may be { SysCapC, sysCapE, …, sysCapZ }; the SysCap set corresponding to TV may be { SysCapC, sysCapE, …, sysCap }; the corresponding SysCap set of the flat plate can be { SysCapA, sysCapE, …, sysCapN }; etc.

The device development platform 203 may be used to support a device vendor to obtain operating system components on the operating system development platform 201, and assemble the operating system components as needed to obtain a system component set (may also be referred to as an OS component set).

The method can also be used for supporting a device manufacturer to define a private part set, and building the private part set and an OS part set into a complete device part set (also called a device SysCap set) to generate a set of operating systems.

And may also be used to support device vendors to deploy the generated operating systems to the user devices 200.

The device SysCap set may also be used to convert the device SysCap set into a PCID of a product compatibility identifier of the device, and send the PCID to the device authentication platform 204, so that the device authentication platform 204 performs device authentication based on the PCID.

The following describes the constitution of PCID based on fig. 4:

as shown in fig. 4, the PCID may be composed of several fields: API version information (apireferences), system type, device vendor ID (ManufactureID, MID), system SysCap set, private SysCap set. Wherein:

the API version information may include, but is not limited to, version name, version number, generation time, etc., and bit0-bit15 may be used to represent the API version information, where the API version information in the PCID may be the API version information of the operating system adopted when the device is developed, and bit15 is fixedly set to 0.

The System types, which may include, but are not limited to, a lightweight System or lightweight System (Mini System), small System, standard System, large System (LargeSystem), etc., bit16-bit31 may be used to represent the System type, where bit16 may represent a lightweight System; bit17 may represent a small system; bit18 may represent a standard system; bit19 may represent a large system; bits 20-31 may represent undefined (reserved) systems. In PCID, if one of bits 16 to 31 is set to 1, the system type is the system type indicated by the bit (for example, if bit16 is 1, it indicates that the system type is a light system), and if all bits are 0 by default, it indicates that the system type is undefined.

A device vendor ID for identifying a unique device vendor information. bits 32-63 may be used to represent the device vendor ID. This field may be set to 0 if there is no extended system capability.

The system SysCap set, the field is encapsulated in TLV format, wherein T is Type, 32bits are all used, bit31 is fixed to 0, and the SysCap set is a system defined SysCap set; l is Length (Length), and the total Length is 16bits, and represents the total Length of the Value field; v is Value, which is greater than or equal to 16bits, and represents system defined SysCapID.

The private SysCap set, the field is also encapsulated in TLV format, wherein T is Type, 32bits are all fixed, bit31 is 1, the SysCap set is the SysCap set expanded by the equipment manufacturer; l is Length, and the total Length of the Value field is represented by 16 bits; v is Value, which is larger than or equal to 16bits, and represents SysCapID extended by equipment manufacturers.

In the embodiment of the application, the system capability can distinguish different attribute groups, such as a basic component set (BaseComponentGroup, BCG), an optional component set (OptionalComponentGroup, OCG) and a private component set (PrivateComponentGroup, PCG), and when the system capability is deployed for multiple devices, the system capability of a specific device is defined in a mode of 'BCG+OCG+PCG'; wherein the BCG may be a minimum component set (e.g., a set of necessary components provided in the operating system development platform 201) corresponding to a certain system type, the OCG may be a system-defined optional component set (e.g., a set of optional components provided in the operating system development platform 201), and the PCG may be a device vendor-defined private component set.

In an embodiment of the present application, a field of "system type" may be used to represent the BCG (e.g., the hong-and-mony authentication minimum component set exemplarily shown in fig. 5A) to which the system type corresponds; the field "System SysCap set" may be used to represent OCG (e.g., the hong option component set exemplarily shown in FIG. 5B); the field "private SysCap set" may be used to represent a PCG (e.g., the Vendor self-grinding component set shown by way of example in FIG. 5C).

The device authentication platform 204, which may also be referred to as a device authentication center or cloud authentication center, may be used to perform device authentication.

Specifically, the device authentication platform 204 may receive the PCID sent by the device development platform 203, then may perform authentication based on the SysCap set included in the PCID, generate a device Token (Token) after the authentication passes, map the PCID with the device Token, store the mapping relationship between the PCID and the device Token, and then may send the device Token corresponding to the PCID to the device development platform 203.

It is to be readily appreciated that the device authentication platform 204 can maintain a mapping relationship between one or more PCIDs and device Token as shown in table 1 below.

PCID	Device Token
		PCID1	Token1
PCID2	Token2
		…	…
PCIDx	Tokenx

TABLE 1

The device authentication platform 204 may also be used to provide functionality for querying and downloading PCIDs.

For example, the application distribution platform 206 may obtain a PCID from the device authentication platform 204. One possible implementation manner is that the application distribution platform 206 may send the device Token to the device authentication platform 204, and the device authentication platform 204 may query the PCID corresponding to the device Token based on the saved mapping relationship between the PCID and the device Token, and send the PCID to the application distribution platform 206.

The application development platform 205 may be used to conduct cross-device application development.

Illustratively, the application development platform 205 may obtain the SDK from the software development kit publishing platform 202, and may then utilize the integrated development environment (IntegratedDevelopmentEnvironment, IDE) to perform application development based on the obtained SDK and define the required product compatibility identifier RPCID of the application. Further, when a developed application needs to be put on-shelf, the RPCID of the application may be sent to the application distribution platform 206.

The following describes the composition of the RPCID based on fig. 6:

as shown in fig. 6, the RPCID may be composed of the following two fields: API version information (apireferences), the required sysacap set. Wherein:

the API version information may include, but is not limited to, version name, version number, generation time, etc., and bit0-bit15 may be used to represent the API version information, where the API version information in the RPCID may be the API version information in the SDK employed when the application is developed, and bit15 is fixedly set to 1.

The required SysCap set, the field is encapsulated in TLV format, wherein T is Type (Type), and the total is 32bits, and the field is used for representing the device Type adapted by the application (the device Type and the specific SysCap set have a one-to-one mapping relation); l is Length (Length), and the total Length is 16bits, and represents the total Length of the Value field; v is Value, which is greater than or equal to 16bits, and represents SysCapID required by the application.

The application distribution platform 206, which may also be referred to as an application marketplace server or an application store server, may be configured to receive and store RPCIDs of applications sent by the application development platform 205; the method can also be used for matching the RPCID of the application with the PCID of the device, and distributing the application to the device (e.g., user device 200) corresponding to the PCID if the range of the RPCID of the application is confirmed to be less than or equal to the range of the PCID of the device. Wherein the PCID of the device is obtained by the application distribution platform 206 from the device authentication platform 204.

The differences in components/controls for the same part across different devices are distributed through a distributer field in the application configuration.

The user device 200 may be used to perform application installation and run the installed application.

Specifically, the ue 200 may include a packet management service module (PackageManagerService, PMS), and the PMS may be configured to analyze the RPCID of the application and the PCID of the device, and determine whether the SysCap set required by the application is less than or equal to the SysCap set of the device, if so, the PMS may confirm that the application may be normally installed and run on the ue 200.

User device 200 may further include a system service management module (also referred to as a system service management component), where the system service management module may include a Samgr component, where the Samgr component is a core component of OpenHarmony and may be used to provide functions of OpenHarmony system service initiation, registration, query, and so on.

In the embodiment of the application, the system management service module (such as a Samgr component) can provide a registration and query interface of the SysCap for each component of the system, can also provide a query interface of the SysCap for the application, and can detect whether the system has the SysCap associated with a certain API before calling the API.

In some embodiments, the device development platform 203 and the application development platform 205 may be the same platform, which may be collectively referred to as a development platform, for example.

The following describes a compatibility management and control method provided by the embodiment of the application.

Fig. 7 illustrates a specific flow of a method for managing and controlling compatibility according to an embodiment of the present application.

As shown in fig. 7, the method can be applied to a communication system including a device development platform, a device authentication platform, an application development platform, an application distribution platform, and user equipment. The specific steps of the method are described in detail below:

Stage one: device development phase

S701, assembling OS components by the device development platform, generating a device SysCap set 1, and compiling and generating a device SysCap configuration file 1 based on the device SysCap set 1.

Specifically, the device development platform may obtain the OS component on the operating system development platform, and the device manufacturer may assemble the OS component on the device development platform as required to generate the device SysCap set 1. Further, the device development platform may compile and generate a device SysCap profile 1 based on the device SysCap set 1.

Among these, device SysCap profile 1 may include, but is not limited to, API version information, device vendor ID, device SysCap set 1 (which may also be referred to as device SysCap list 1).

In some embodiments, not only the set of OS components but also the set of device vendor defined private components may be included in the device SysCap set 1.

S702, the device development platform encodes the device SysCap configuration file 1 by using a SysCap encoding and decoding tool to generate the PCID1.

Specifically, after the device SysCap configuration file 1 is generated, the device development platform may use the API version information, the device vendor ID, the device SysCap set 1 and other information in the device SysCap configuration file 1 as input data of a SysCap codec tool, and encode the device SysCap configuration file 1 by using the SysCap codec tool to generate PCID1.

It should be noted that, in the embodiment of the present application, the encoding mode used when the SysCap codec tool encodes the device SysCap configuration file 1 is not limited.

Stage two: device authentication phase

S703, the device development platform sends a device authentication request 1 to the device authentication platform, where the request includes PCID1.

Specifically, after generating PCID1, the device development platform may send a device authentication request 1 to the device authentication platform, where PCID1 may be included in the device authentication request 1.

Wherein, the PCID1 may be used for the device authentication platform to perform device authentication based on the PCID1.

S704-S706, the device authentication platform confirms that the device authentication passes, generates a device Token1, and stores the mapping relation between the PCID1 and the Token1. Then, the device authentication platform may send Token1 to the device development platform, and after receiving Token1 sent by the device authentication platform, the device development platform may store Token1.

Specifically, the device authentication platform may perform device authentication based on the SysCap set included in the PCID after receiving the PCID1 sent by the device development platform, and may generate the device Token1 after confirming that the device authentication passes, and may store the PCID1, and store a mapping relationship between the PCID1 and the Token1.

Then, the device authentication platform may send Token1 to the device development platform, and the device development platform may save Token1 after receiving Token1 sent by the device authentication platform.

The Token1 may be used to obtain PCID1 from the device authentication platform in a subsequent step.

Stage three: application development phase

S707, the application development platform generates a device SysCap set 1 based on the SDK1 or the PCID1, and performs API static check.

The manner in which the application development platform generates the device SysCap collection is also different for different device types.

In the embodiment of the present application, device types can be classified into two main types: 1+8 devices, N devices.

The 1+8 equipment can be an explosion type electronic equipment, and the explosion type electronic equipment can comprise a mobile phone, a PC, a flat plate, an intelligent screen, a sound box, a watch, glasses, a car machine and an earphone.

The N devices may be other electronic devices except the above-mentioned burst electronic device, for example, electronic devices including a camera, a sweeping robot, an intelligent scale, etc. covering multiple scene modes such as mobile office, intelligent home, sports health, audio-visual entertainment, and intelligent trip.

Referring to fig. 8, first, before developing an application, the application development platform may determine the device type adapted to the application (i.e., step S801).

If the application development platform confirms that the device type is N devices (i.e. step S802 a), the application development platform may decode the PCID of the device imported by the application developer using the SysCap codec tool to generate a device SysCap set (i.e. step S803 a).

If the application development platform confirms that the device type is 1+8 devices (i.e. step S802 b), since the SDK corresponding to 1+8 devices has been issued on the SDK issuing platform and the device SysCap set corresponding to 1+8 devices has been defined in the SDK, the application development platform may acquire the SDK corresponding to 1+8 devices from the SDK issuing platform and acquire the device SysCap set based on the SDK (i.e. step S803 b).

Further, after the device SysCap set is generated, the application development platform may perform API static inspection based on the device SysCap set and the SysCap attribute of the API (i.e. step S805), so as to enhance the experience of the developer. Optionally, API associations may also be made.

Wherein, the prior art may be used for both static checking of the API (i.e. static checking of the call to the API) and association of the API, and will not be described herein.

It is easy to understand that if SDK1 is an SDK corresponding to a 1+8 device (e.g., a mobile phone), the application development platform may generate device SysCap set 1 based on SDK 1; if PCID1 is the PCID corresponding to the N devices (e.g., the sweeping robot), the application development platform may generate device SysCap set 1 based on PCID 1.

S708, the application development platform compiles and generates an application SysCap configuration file 1 based on the device SysCap set 1 and the application SysCap set 1.

With continued reference to fig. 8, the application development platform may compile and generate an application SysCap configuration file based on the device SysCap set and the application SysCap set (i.e., step S804), where the application SysCap configuration file may include a "device type" field and a "required device SysCap" field.

The setting modes of the device type (device_type) field and the required device SysCap (required_device_map) field in the application SysCap configuration file are different.

Assuming that the device SysCap set is the device SysCap set 1, the application SysCap set is the application SysCap set 1, and the application SysCap profile is the application SysCap profile 1.

If the device SysCap set 1 is obtained by decoding the PCID of the device, the device type of the application is N device, further, the application development platform may set the content corresponding to the "device type" field to be null, and the application development platform may define the whole amount of the SysCap required by the application in the "required device_device_sycap" field, that is, write all of the SysCap required by the application into the application SysCap configuration file 1, for example, the required SysCap of the application is SysCapA, sysCapB, sysCapC, and the content corresponding to the "required device SysCap (required_device_sycap)" field in the application configuration file 1 is SysCapA, sysCapB, sysCapC. It will be readily appreciated that in this case, the application SysCap set 1 includes only the SysCap corresponding to the "required device SysCap (required device SysCap)" field in the application profile 1, for example SysCapA, sysCapB, sysCapC.

If the device SysCap set 1 is obtained through the SDK, the device type of the application is 1+8 devices, further, the application development platform may not set the content corresponding to the device type field to null, and if the SysCap required by the application includes a SysCap other than the SysCap set included by the corresponding device type, the application development platform may perform incremental definition on the SysCap required by the application in the required device SysCap field to include a SysCap other than the SysCap set included by the corresponding device type, i.e. write the SysCap required by the application into the application SysCap configuration file 1 in an incremental form. For example, if the device type is a mobile phone, the content corresponding to the "device type" field in the application SysCap configuration file 1 is phone, and if the SysCap required by the application includes a SysCap other than the SysCap set included in the device type of the mobile phone, for example, sysCapD, sysCapE, the content corresponding to the "required device SysCap (required device) system" field in the application configuration file 1 is SysCapD, sysCapE. It will be readily understood that in this case, the application SysCap set 1 includes not only the SysCap corresponding to the "required device SysCap (required device_syscap)" field in the application profile 1, for example SysCapD, sysCapE, but also the SysCap included in the device SysCap set 1.

S709, the application development platform encodes the application SysCap configuration file 1 by using a SysCap encoding and decoding tool to generate the RPCID1.

With continued reference to fig. 8, after generating the application SysCap configuration file, the application development platform may encode the application SysCap configuration file with a SysCap codec tool to generate an RPCID for the application (i.e., step S806).

The content of the field "API version information" in the RPCID of the application may be obtained based on the API version information in the SDK or PCID.

It is easy to understand that in the case of a device type of 1+8 devices, the content of the field "API version information" in the RPCID of the application may be derived based on the API version information in the SDK; in the case where the device type is N devices, the content of the field "API version information" in the RPCID of the application may be obtained based on the API version information in the PCID.

The content of the field "required SysCap set" in the RPCID of the application may be obtained only based on the SysCap corresponding to the "required device SysCap" field in the application SysCap configuration file; or, the device type information may be obtained based on a SysCap (required device_syscap) corresponding to a "required device_syscap" field and a SysCap included in a device type corresponding to a "device type" field in the application SysCap configuration file.

It is easy to understand that, in the case where the device type is 1+8 devices, the content of the field "required SysCap set" in the RPCID of the application may be obtained based on the SysCap corresponding to the "required device SysCap (required device_sycap)" field and the SysCap included in the device type corresponding to the "device type" field in the application SysCap configuration file; in the case that the device type is N devices, the content of the field "required SysCap set" in the RPCID of the application may be obtained only based on the SysCap corresponding to the "required device SysCap (required device SysCap)" field in the application SysCap configuration file.

In the embodiment of the application, the application development platform can utilize the SysCap codec tool to encode the application SysCap configuration file 1 to generate the RPCID1 of the application.

S710-S711, the application development platform sends the RPCID1 to the application distribution platform, and after the application distribution platform receives the RPCID1 sent by the application development platform, the RPCID1 can be saved.

Specifically, after the application development platform generates the RPCID1, when the application corresponding to the RPCID1 needs to be put on shelf, the application development platform may send the RPCID1 to the application distribution platform, and after the application distribution platform receives the RPCID1 sent by the application development platform, the application distribution platform may save the RPCID1, so that a subsequent application distribution platform may generate a SysCap set (i.e., an application SysCap set) corresponding to the application based on the RPCID1.

Stage four: application distribution phase

S712-S714, the device development platform performs OS deployment (sending the device SysCap set 1, token1 and the like) to the user device, the user device stores the device SysCap set 1 and Token1, and sends Token1 to the application distribution platform.

Specifically, the device development platform may perform OS deployment to the user device after passing the device authentication (i.e., after completion of the execution of step S706). For example, the device development platform may send information such as the device SysCap set 1 and Token1 to the user device, and after the user device receives the information such as the device SysCap set 1 and Token1 sent by the device development platform, the user device may save the information such as the device SysCap set 1 and Token1, and further, the user device may deploy the OS based on the device SysCap set 1.

Further, the user device may further send Token1 to the application distribution platform, so that the application distribution platform may obtain, from the device authentication platform, the PCID corresponding to Token1 based on Token1.

Note that, the timing of executing step S712 to step S714 is not limited in the embodiment of the present application. For example, step S712 to step S714 may be performed after step S706 is performed; for another example, step S712-step S714 may be performed simultaneously with the step in the third stage; for another example, step S712 to step S714 may be performed after the step in the third stage is performed; etc.

S715-S717, the application distribution platform sends a request for obtaining the PCID to the device authentication platform, wherein the request can comprise Token1, and after the device authentication platform receives the request for obtaining the PCID sent by the application distribution platform, the device authentication platform can confirm that the Token1 corresponds to the PCID1 based on the mapping relation between the PCID and the Token. Thereafter, the device authentication platform may send PCID1 to the application distribution platform.

Specifically, after receiving the Token1 sent by the user equipment, the application distribution platform may send a request for obtaining the PCID to the device authentication platform, where the request may include the Token1, and after receiving the request for obtaining the PCID sent by the application distribution platform, the device authentication platform stores in advance a mapping relationship between the PCID and the Token, so that the device authentication platform may confirm that the PCID corresponding to the Token1 is the PCID1 based on the mapping relationship between the PCID stored in advance and the Token. Thereafter, the device authentication platform may send PCID1 to the application distribution platform.

In some embodiments, step S715 is optional. For example, the device authentication platform may actively send all PCIDs and Token and the mapping relationship of each PCID and Token to the application distribution platform, and the application distribution platform may determine that Token1 corresponds to PCID1 based on the mapping relationship of each PCID and Token.

In some embodiments, where step S715 is an optional step, step S714 is also optional, that is, step S714 need not be performed without performing step S715.

S718, the application distribution platform decodes the PCID1 and the RPCID1 by using a SysCap coding and decoding tool to sequentially obtain a device SysCap set 1 and an application SysCap set 1.

Specifically, after receiving the PCID1 sent by the device authentication platform, the application distribution platform may decode with the SysCap codec tool PCID1 to obtain the device SysCap set 1.

The application distribution platform can also decode the RPCID1 by using a SysCap codec tool to obtain an application SysCap set 1. The RPCID1 is sent to the application distribution platform by the application development platform, and the application distribution platform is stored.

It should be noted that, in the embodiment of the present application, the timing of decoding the RPCID1 by using the SysCap codec tool to obtain the application SysCap set 1 by the application distribution platform is not limited. For example, the application distribution platform may decode the RPCID1 by using the SysCap codec tool after receiving the RPCID1 sent by the application development platform (i.e., after the execution of step S710 is completed) to obtain an application SysCap set 1; for another example, the application distribution platform may, after receiving the PCID1 sent by the device authentication platform (i.e., after the execution of step S717 is completed), decode the RPCID1 stored in advance (i.e., the RPCID1 stored in step S711) by using the SysCap codec tool to obtain the application SysCap set 1.

S719, the application distribution platform confirms that the range of the application SysCap set 1 is smaller than or equal to the range of the device SysCap set 1.

Specifically, after the device SysCap set 1 and the application SysCap set 1 are obtained by decoding, the application distribution platform may determine whether the range of the application SysCap set 1 is smaller than or equal to the range of the device SysCap set 1, if yes, the application distribution platform continues to execute the following step S720, that is, the application distribution platform confirms that the user equipment has the system capability necessary for the application corresponding to the application SysCap set 1, and distributes the application corresponding to the application SysCap set 1 to the user equipment; if not, the application distribution platform does not execute step S720, in which the application distribution platform confirms that the user device does not have the system capability necessary for the application corresponding to the application SysCap set 1, and does not distribute the application corresponding to the application SysCap set 1 to the user device.

It is easy to understand that in the embodiment of the present application, the range of the application SysCap set 1 is smaller than or equal to the range of the device SysCap set 1, which means that the application SysCap set 1 is included in the device SysCap set 1, that is, the application SysCap set 1 is a subset of the device SysCap set 1.

S720, the application distribution platform sends an application installation request to the user equipment, wherein the request comprises RPCID1.

Specifically, after confirming that the range of the application SysCap set 1 is less than or equal to the range of the device SysCap set 1, the application distribution platform may send an application installation request (i.e., a request for installing an application corresponding to the application SysCap set 1) to the user device, where the request includes the RPCID1.

Stage five: application installation phase

S721, the user equipment decodes the RPCID1 by using a SysCap encoding and decoding tool to obtain an application SysCap set 1.

Specifically, after receiving the application installation request sent by the application distribution platform, referring to fig. 9, the packet management service module PMS of the user equipment may decode the RPCID carried in the application installation request by using the SysCap codec tool to obtain an application SysCap set (i.e. step S901).

Illustratively, in the above step S720, if the RPCID carried in the application installation request is RPCID1, after receiving the application installation request sent by the application distribution platform, the PMS of the user equipment may decode the RPCID1 by using the SysCap codec tool to obtain the application SysCap set 1.

S722, the user equipment judges whether the range of the application SysCap set 1 is smaller than or equal to the range of the current equipment SysCap set, if yes, the application can be installed on the equipment and normally operated.

Specifically, referring to fig. 9, after receiving an application installation request sent by an application distribution platform, the PMS of the user equipment may decode RPCID1 in the application installation request by using a SysCap codec tool to obtain an application SysCap set 1, and may also obtain a current device SysCap set of the user equipment by calling a query interface of the SysCap provided by a Samgr component in a system management service module (i.e. step S902).

Referring to fig. 10, in an embodiment of the present application, in one aspect, a Samgr component may provide a registration interface and a query interface for each component of the system (e.g., component a, component B, etc.), for example, the system may send a request to the Samgr component to register the component (RegSysCap), and the Samgr component may perform a registration process and then return a registration result (true/false); for another example, the system may send a request to the Samgr component to query the component (quasysc ap), which may query the corresponding component, and then return a query result (true/false). On the other hand, the Samgr component may also provide a query interface for a SysCap for an Application (APP), the Application may detect whether the system has the SysCap associated with a certain API before calling the certain API, for example, the Application needs to call the certain API, the Application may send a request for querying a component (hasSysCap) associated with the API to the Samgr component, the Samgr component may query a corresponding component, and then return a query result (true/false), if the query result is true, it indicates that the system has the SysCap associated with the API, and further, the Application may call the API to perform a corresponding function.

After the PMS of the user equipment obtains the current device SysCap set of the user equipment by calling the query interface of the SysCap provided by the Samgr component in the system management service module, it may be judged whether the range of the application SysCap set is less than or equal to the range of the current device SysCap set of the user equipment (i.e. step S903), if so, the PMS of the user equipment may confirm that the application may be installed and normally run on the user equipment (i.e. step S904), and if not, the PMS of the user equipment may confirm that the application may not be installed on the user equipment (i.e. step S905).

In step S722, the application SysCap set is an application SysCap set 1, and the PMS of the user device may determine whether the range of the application SysCap set 1 is smaller than or equal to the range of the current device SysCap set of the user device, if so, it is confirmed that the application corresponding to the application SysCap set 1 may be installed and normally operated on the user device, that is, if the range of the application SysCap set 1 is smaller than or equal to the range of the current device SysCap set of the user device, the application corresponding to the application SysCap set 1 may be successfully installed and normally operated on the user device.

For example, as shown in fig. 11A, the user interface shown in fig. 11A may be a "recommended" interface for an application, an application marketplace (also referred to as an application store) on the user device, in which information for one or more applications recommended to the user (e.g., information for application 1 icon, application 2 icon, application 3 icon, application 4 icon, etc.) may be displayed. The application SysCap sets of the applications are all smaller than or equal to the device SysCap set of the user device in scope.

That is, an application may be displayed in the "recommended" interface of the application marketplace and support a user to install the application to a user device only if the application sysCap set of the application has a range less than or equal to the device sysCap set of the user device.

Further, if the user wants to install a certain application, for example, application 1, the user may click on the installation option corresponding to application 1, after the installation is successful, the user device may display the opening option corresponding to application 1 in fig. 11B, and the user may open the application by clicking on the opening option.

Illustratively, as shown in FIG. 11C, the user interface shown in FIG. 11C may be a "search" interface for an application on the user device that applies to the marketplace, and if the user wants to install an application, e.g., an XX application, on the user device, the user may enter the "XX application" in the search box shown in FIG. 11C.

If the range of the application SysCap set of the XX application is smaller than or equal to the device SysCap set of the user device, the user device may display information that the application may be installed on the user device in the user interface shown in fig. 11C, for example, display an installation option corresponding to the application, and the user may install the application by clicking the installation option.

If the range of the application SysCap set of the XX application is larger than the device SysCap set of the user device, the user device may display information that the application cannot be installed on the user device in the user interface shown in fig. 11D, for example, an icon of the application and a name of the application, and an option corresponding to the application that cannot be installed may be displayed in a gray scale, so as to prompt the user that the application cannot be installed on the user device.

In some embodiments, step S722 is optional, that is, the user device does not need to determine whether the range of the application SysCap set 1 is less than or equal to the range of the current device SysCap set, since the application distribution platform has already confirmed that the range of the application SysCap set 1 is less than or equal to the range of the device SysCap set 1 before distributing the application.

In some embodiments, in the case that the scope of the application SysCap set 1 is greater than the scope of the current device SysCap set of the user equipment, the application corresponding to the application SysCap set 1 may enable the application to run normally on the user equipment through the installation-free procedure.

By implementing the method provided by the embodiment shown in fig. 7, the problem of compatibility between the application and the device after the OS is elastically deployed can be solved by using the PCID and the RPCID, in addition, before the device is released, the number of applications available to the device provided on the application distribution platform can be obtained based on the PCID stored in the device authentication platform, and in addition, an application developer can be advanced to develop core applications (such as system applications), so that the time for the device to be marketed is shortened.

It should be noted that, in the embodiment shown in fig. 7, each stage may exist independently, that is, the corresponding steps in the stage may be performed independently of the steps in the other stages; it is also possible that several phases may be freely combined, i.e. the respective steps of these phases may be performed independently of the steps of the other phases, which is not limited by the embodiment of the application.

In the embodiment of the present application, the first identifier may be a PCID, the second identifier may be an RPCID, the first device SysCap set may be a device SysCap set 1, the first application SysCap set may be an application SysCap set 1, the first request may be an application installation request, the first application may be an application corresponding to the application SysCap set 1, the first PCID may be a PCID1, the first RPCID may be an RPCID1, the first SDK may be an SDK1, the first information may be an SDK1 or a PCID1, the first type of user device may include, but is not limited to, a mobile phone, a PC, a tablet, a smart screen, a sound box, a watch, glasses, a car set, and an earphone, the second request may be a device authentication request 1, the first Token may be a Token1, the third request may be a request for obtaining a PCID, the first user interface may be a user interface shown in fig. 11A or fig. 11C, and the first option may be an installation option shown in fig. 11A or 11C.

The following describes a software structure of a user device (may also be referred to as an electronic device 100) provided in an embodiment of the present application.

Fig. 12 schematically shows a software structure of an electronic device 100 provided in an embodiment of the application.

As shown in fig. 12, the software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the application, taking an Android system with a layered architecture as an example, a software structure of the electronic device 100 is illustrated.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages.

As shown in fig. 12, the application package may include applications for cameras, gallery, calendar, phone calls, maps, application markets, WLAN, bluetooth, music, video, short messages, etc.

Wherein the application marketplace may be used to download installed applications.

It should be noted that, the names of the application market application programs are only words used in the embodiments of the present application, and their meaning is already described in the embodiments of the present application, and the names should not be construed as limiting the embodiments of the present application.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. The application framework layer includes a number of predefined functions.

As shown in fig. 12, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc.

The view system includes visual controls, such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The telephony manager is used to provide the communication functions of the electronic device 100. Such as the management of call status (including on, hung-up, etc.).

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The notification manager allows the application to display notification information in a status bar, can be used to communicate notification type messages, can automatically disappear after a short dwell, and does not require user interaction. Such as notification manager is used to inform that the download is complete, message alerts, etc. The notification manager may also be a notification in the form of a chart or scroll bar text that appears on the system top status bar, such as a notification of a background running application, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in a status bar, a prompt tone is emitted, the electronic device vibrates, and an indicator light blinks, etc.

Android run time includes a core library and virtual machines. Android run time is responsible for scheduling and management of the Android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio and video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

The 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The kernel layer at least comprises a display driver, a camera driver, a Bluetooth driver and a sensor driver.

In the embodiment of the present application, the software architecture of the electronic device 100 may further include a package management service module (not shown in the figure) and a system service management module (not shown in the figure), where specific functions and working details of the two modules may refer to relevant contents in the foregoing embodiments, which are not described herein again.

The workflow of the electronic device 100 software and hardware is illustrated below in connection with capturing a photo scene.

When touch sensor 180K receives a touch operation, a corresponding hardware interrupt is issued to the kernel layer. The kernel layer processes the touch operation into the original input event (including information such as touch coordinates, time stamp of touch operation, etc.). The original input event is stored at the kernel layer. The application framework layer acquires an original input event from the kernel layer, and identifies a control corresponding to the input event. Taking the touch operation as a touch click operation, taking a control corresponding to the click operation as an example of a control of a camera application icon, the camera application calls an interface of an application framework layer, starts the camera application, further starts a camera driver by calling a kernel layer, and captures a still image or video by the camera 193.

The following describes a structure of a user device (may also be referred to as an electronic device 100) provided in an embodiment of the present application.

Fig. 13 exemplarily shows a structure of an electronic apparatus 100 provided in an embodiment of the present application.

As shown in fig. 13, the electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and a command center of the electronic device 100, among others. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

The I2C interface is a bi-directional synchronous serial bus comprising a serial data line (SDA) and a serial clock line (derail clock line, SCL). In some embodiments, the processor 110 may contain multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc., respectively, through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, such that the processor 110 communicates with the touch sensor 180K through an I2C bus interface to implement a touch function of the electronic device 100.

The I2S interface may be used for audio communication. In some embodiments, the processor 110 may contain multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 via an I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface, to implement a function of answering a call through the bluetooth headset.

PCM interfaces may also be used for audio communication to sample, quantize and encode analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled through a PCM bus interface. In some embodiments, the audio module 170 may also transmit audio signals to the wireless communication module 160 through the PCM interface to implement a function of answering a call through the bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus for asynchronous communications. The bus may be a bi-directional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is typically used to connect the processor 110 with the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through a UART interface, to implement a function of playing music through a bluetooth headset.

The MIPI interface may be used to connect the processor 110 to peripheral devices such as a display 194, a camera 193, and the like. The MIPI interfaces include camera serial interfaces (camera serial interface, CSI), display serial interfaces (display serial interface, DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the photographing functions of electronic device 100. The processor 110 and the display 194 communicate via a DSI interface to implement the display functionality of the electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal or as a data signal. In some embodiments, a GPIO interface may be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, and the like. The GPIO interface may also be configured as an I2C interface, an I2S interface, a UART interface, an MIPI interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other terminal devices, such as AR devices, etc.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also employ different interfacing manners in the above embodiments, or a combination of multiple interfacing manners.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charge management module 140 may receive a charging input of a wired charger through the USB interface 130. In some wireless charging embodiments, the charge management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device 100 through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be configured to monitor battery capacity, battery cycle number, battery health (leakage, impedance) and other parameters. In other embodiments, the power management module 141 may also be provided in the processor 110. In other embodiments, the power management module 141 and the charge management module 140 may be disposed in the same device.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low frequency baseband signal to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs sound signals through an audio device (not limited to the speaker 170A, the receiver 170B, etc.), or displays images or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional module, independent of the processor 110.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques. The wireless communication techniques may include the Global System for Mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED) or an active-matrix organic light-emitting diode (matrix organic light emitting diode), a flexible light-emitting diode (flex), a mini, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and is converted into an image visible to naked eyes. ISP can also optimize the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, or the like.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

The internal memory 121 may be used to store computer executable program code including instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals. The electronic device 100 may listen to music, or to hands-free conversations, through the speaker 170A.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal. When electronic device 100 is answering a telephone call or voice message, voice may be received by placing receiver 170B in close proximity to the human ear.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can sound near the microphone 170C through the mouth, inputting a sound signal to the microphone 170C. The electronic device 100 may be provided with at least one microphone 170C. In other embodiments, the electronic device 100 may be provided with two microphones 170C, and may implement a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may also be provided with three, four, or more microphones 170C to enable collection of sound signals, noise reduction, identification of sound sources, directional recording functions, etc.

The earphone interface 170D is used to connect a wired earphone. The earphone interface 170D may be a USB interface 130 or a 3.5mm open mobile terminal platform (open mobile terminal platform, OMTP) standard interface, a american cellular telecommunications industry association (cellular telecommunications industry association of the USA, CTIA) standard interface.

The touch sensor 180K, also referred to as a "touch panel". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 100 at a different location than the display 194.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 191 may also correspond to different vibration feedback effects by touching different areas of the display screen 194. Different application scenarios (such as time reminding, receiving information, alarm clock, game, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card may be inserted into the SIM card interface 195, or removed from the SIM card interface 195 to enable contact and separation with the electronic device 100. The electronic device 100 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support Nano SIM cards, micro SIM cards, and the like. The same SIM card interface 195 may be used to insert multiple cards simultaneously. The types of the plurality of cards may be the same or different. The SIM card interface 195 may also be compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as communication and data communication. In some embodiments, the electronic device 100 employs esims, i.e.: an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

It should be understood that the electronic device 100 shown in fig. 13 is only one example, and that the electronic device 100 may have more or fewer components than shown in fig. 13, may combine two or more components, or may have a different configuration of components. The various components shown in fig. 13 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims

1. A communication system, comprising a development platform, an application distribution platform, and a user device, wherein:

the development platform is used for: acquiring one or more components and generating a first identification based on the one or more components; the first identifier is used for indicating a first device system capability SysCap set, and the first device SysCap set is a SysCap set of an operating system of the user equipment;

Acquiring a second identifier; the second identifier is used for indicating a first application SysCap set, and the first application SysCap set is a SysCap set required by the first application when installed and operated on the user equipment;

the application distribution platform is used for: receiving the second identification sent by the development platform;

acquiring the first identifier;

in the case that the first device SysCap set comprises the first application SysCap set based on the first identifier and the second identifier, sending a first request to the user equipment, wherein the first request is used for indicating the user equipment to install the first application;

the user equipment is used for: the first application is installed.

2. The communication system of claim 1, wherein the first identifier is a first product compatibility identifier, PCID, and the second identifier is a first required product compatibility identifier, RPCID.

3. The communication system according to claim 1 or 2, further comprising a device authentication platform for:

receiving and storing the first identification sent by the development platform;

And sending the first identification to the application distribution platform.

4. A method for controlling compatibility, applied to an application distribution platform, the method comprising:

the application distribution platform acquires a first identifier, wherein the first identifier is used for indicating a first device system capability SysCap set, and the first device SysCap set is a SysCap set of an operating system of user equipment;

the application distribution platform acquires a second identifier, wherein the second identifier is used for indicating a first application SysCap set, and the first application SysCap set is a SysCap set required by the first application when the first application is installed and operated on the user equipment;

the application distribution platform sends a first request to the user equipment, wherein the first request is used for indicating the user equipment to install the first application, when the first device SysCap set comprises the first application SysCap set based on the first identifier and the second identifier.

5. The method of claim 4, wherein the first identifier is a first product compatibility identifier, PCID, and the second identifier is a first required product compatibility identifier, RPCID.

6. The method of claim 5, wherein the application distribution platform obtains the first identifier, specifically comprising:

the application distribution platform acquires the first PCID from the equipment authentication platform;

the first PCID is generated by a development platform based on the first device SysCap set and sent to the device authentication platform.

7. The method according to claim 5 or 6, wherein the application distribution platform obtains the second identifier, specifically comprising:

the application distribution platform receives a first RPCID sent by a development platform;

the first RPCID is generated by the development platform based on the first application SysCap set, and the first application SysCap set is generated by the application distribution platform based on a first SDK or the first PCID issued on a software development kit SDK issue platform.

8. A compatibility management and control method applied to a development platform, the method comprising:

the development platform acquires first information, wherein the first information comprises a first Software Development Kit (SDK) or a first identifier, the first identifier is used for indicating a first device system capability (SysCap) set, and the first device SysCap set is a SysCap set of an operating system of the user equipment;

The development platform generates a second identifier based on the first information, wherein the second identifier is used for indicating a first application SysCap set, and the first application SysCap set is a SysCap set required by the first application when being installed and operated on the user equipment;

the development platform sends the second identification to an application distribution platform.

9. The method of claim 8, wherein the first identifier is a first product compatibility identifier, PCID, and the second identifier is a first required product compatibility identifier, RPCID.

10. The method according to claim 9, wherein the development platform generates a second identification based on the first information, in particular comprising:

in the case that the device type of the user device is a first type, the development platform generates the first RPCID based on the first SDK;

or alternatively, the first and second heat exchangers may be,

in the case that the device type of the user device is not the first type, the development platform generates the first RPCID based on the first PCID.

11. The method of any of claims 8-10, wherein prior to the development platform obtaining the first information, the method further comprises:

The development platform obtains one or more components and generates the first identification based on the one or more components.

12. The method of claim 11, wherein the development platform generates the first identification based on the one or more components, specifically comprising:

the development platform generating the first device SysCap set based on the one or more components;

the development platform encodes the first device SysCap set to generate the first PCID.

13. The method of claim 11 or 12, wherein after the development platform generates the first identification based on the one or more components, the method further comprises:

the development platform sends a second request to the equipment authentication platform, wherein the second request comprises the first PCID;

and under the condition that the device authentication platform confirms that the device authentication passes based on the first PCID, the development platform receives and stores a first Token transmitted by the device authentication platform.

14. A method of compatibility management and control applied to a user equipment, the method comprising:

the user equipment receives a first request sent by an application distribution platform, wherein the first request comprises a first Required Product Compatibility Identifier (RPCID);

The user equipment installs a first application under the condition that the user equipment determines that a first equipment SysCap set comprises the first application SysCap set based on the first RPCID and a first product compatibility identifier PCID;

the first PCID is used to indicate a first application SysCap set, where the first application SysCap set is a SysCap set required when the first application is installed and run on the user equipment, and the first PCID is used to indicate a first device system capability SysCap set, where the first device SysCap set is a SysCap set of an operating system of the user equipment.

15. The method of claim 14, wherein the user device comprises an application package management service PMS and Samgr component, wherein the user device determines, based on the first RPCID and a first product compatibility identification PCID, that a first device SysCap set comprises the first application SysCap set, specifically comprising:

the user equipment decodes the first RPCID by utilizing the PMS to generate the first application SysCap set;

the user equipment queries the first equipment SysCap set by utilizing the Samgr component;

the user equipment determines that the first device SysCap set includes the first application SysCap set using the PMS.

16. The method according to claim 14 or 15, wherein before the user device installs the first application, the method further comprises:

the user equipment displays a first user interface, wherein the first user interface comprises a first option, and the first option is an option for installing the first application;

the user device detects a user operation with respect to the first option.

17. An electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories for storing computer program code comprising computer instructions that, when executed by the one or more processors, cause the electronic device to perform the method of any of claims 4-7 or 8-13 or 14-16.

18. A computer storage medium storing a computer program comprising program instructions which, when run on an application distribution platform, cause the application distribution platform to perform the method of any of claims 4-7 or 8-13 or 14-16.