Method for calling application program interface and electronic equipment

Abstract

The invention provides a method for calling an application program interface and electronic equipment. In the method, the electronic equipment contains capability information, the capability information indicates at least one capability which can be called by a first application, and the method comprises the following steps: calling a first application program interface in response to the first application, and obtaining the capability information; and if the first capability for providing the first application program interface is included in the at least one capability indicated by the capability information, allowing the first application to call the first application program interface. According to the method provided by the invention, whether the first application can call the first application program interface or not can be authenticated without interaction between the electronic equipment and the cloud server, so that the authentication performance is improved.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for calling an application programming interface and an electronic device. Background Technology

[0002] When a third-party application in an electronic device calls an application programming interface (API), the electronic device needs to authenticate the third-party application that calls the API, that is, to authorize the caller of the API. Only when the authentication is successful will the API be allowed to be called.

[0003] However, current electronic devices have poor authentication performance when authenticating callers of application programming interfaces (APIs). Summary of the Invention

[0004] This application provides a method for calling an application programming interface (API) and an electronic device to improve authentication performance.

[0005] In a first aspect, this application provides a method for calling an application programming interface (API), applied to an electronic device, the electronic device containing capability information indicating at least one capability that a first application can call, the method comprising: when the first application triggers a request to call a first API, obtaining the capability information; if the first capability providing the first API is included in at least one capability indicated by the capability information, allowing the first application to call the first API.

[0006] In this technical solution, the electronic device includes capability information for indicating at least one capability that the first application can call. Thus, when the first application calls the first application interface, the electronic device can determine whether the first capability providing the first application interface is included in at least one capability that the first application can call based on the capability information, thereby determining whether the first application has the permission to call the first application interface.

[0007] This technical solution allows for authentication of whether a first application can call the first application interface without the need for interaction between electronic devices and the cloud server. This avoids issues such as the first application being unable to call the first application interface due to problems with the cloud server, resulting in low security, and the time-consuming authentication process via the cloud server. Therefore, it can improve the authentication performance of the first application calling the first application interface.

[0008] In one possible implementation, the method further includes: if the first capability providing the first application interface is not included in at least one capability indicated by capability information, the first application is not allowed to call the first application interface.

[0009] In one possible implementation, the capability information is contained in a first file of the first application. For example, the first file is the profile file of the first application.

[0010] In one possible implementation, the electronic device includes a first management module for acquiring capability information, including: acquiring capability information from the first management module; wherein the first management module acquires the capability information during the process of installing the first application into the electronic device.

[0011] Secondly, this application provides an electronic device that calls an application programming interface (API), the electronic device comprising:

[0012] The capability query module is used to obtain capability information when the first application triggers a request to call the first application interface. The capability information indicates at least one capability that the first application can call.

[0013] A verification module is configured to allow a first application to call the first application interface if the first capability providing the first application interface is included in at least one capability indicated by capability information.

[0014] In one possible implementation, the verification module is further configured to: disallow the first application from calling the first application interface if the first capability providing the first application interface is not included in at least one capability indicated by the capability information.

[0015] In one possible implementation, the capability information is contained in the first file of the first application.

[0016] In one possible implementation, the first file is the Profile file of the first application.

[0017] In one possible implementation, the electronic device includes a first management module, and the capability query module is specifically used to: obtain capability information from the first management module;

[0018] The first management module acquires capability information during the installation of the first application onto the electronic device.

[0019] Thirdly, this application provides an electronic device including one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer instructions, which, when executed by the one or more processors, cause the electronic device to implement the method device as described in the first aspect and any possible implementation of the first aspect.

[0020] Fourthly, this application provides a computer-readable storage medium that stores program code for execution by a computer, the program code including instructions for implementing the method described in the first aspect and any possible implementation thereof.

[0021] Fifthly, this application provides a chip on which a computer program is stored. When the computer program is executed by the chip, it implements the method described in the first aspect and any possible implementation of the first aspect.

[0022] In a sixth aspect, this application provides a computer program product comprising instructions for implementing the methods described in the first aspect and any possible implementation thereof. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application;

[0024] Figure 2 This is a software structure block diagram of a terminal device to which this application embodiment applies;

[0025] Figure 3 A flowchart illustrating a method for invoking an application programming interface (API) according to an embodiment of this application;

[0026] Figure 4 This is a schematic diagram illustrating the writing of capability information into a profile file, as provided in this application.

[0027] Figure 5 A schematic diagram illustrating the process of authenticating a first application calling a first application programming interface, as provided in one embodiment of this application.

[0028] Figure 6 A schematic diagram of an interface provided by an AGC according to one embodiment of this application;

[0029] Figure 7 A schematic diagram of an electronic device that calls an application programming interface according to one embodiment of this application;

[0030] Figure 8 A schematic diagram of an electronic device that calls an application programming interface, provided for another embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0032] Before introducing the technical solutions provided in the embodiments of this application, the following points should be noted:

[0033] First, the use of prefixes such as "first" and "second" in this application is solely for the purpose of distinguishing and describing different things belonging to the same category, and does not constrain the order, size, or quantity of things. For example, "first information" and "second information" are simply different pieces of information, and there is no temporal sequence, size, or priority relationship between them.

[0034] Second, in this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates an "or" relationship between the preceding and following related objects, but it does not exclude the possibility of indicating an "and" relationship; the specific meaning can be understood in context. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c; a and b; a and c; b and c; or a and b and c. Here, a, b, and c can be single or multiple.

[0035] Third, in the embodiments of this application, "when," "if," and "if" all refer to the electronic device making a corresponding processing under certain objective circumstances, and are not limited to a time, nor do they require the electronic device to make a judgment when it implements the processing, nor do they imply any other limitations.

[0036] Fourth, in this application, the words "example," "exemplarily," "for example," or "such as" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "example," "exemplarily," "for example," or "such as" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "example," "exemplarily," "for example," or "such as" is intended to present the relevant concepts in a specific manner.

[0037] The method for calling application programming interfaces (APIs) provided in this application can be applied to electronic devices. Electronic devices can also be called terminal devices. Electronic devices can be mobile phones, tablets, personal computers (PCs), smart screens, in-vehicle systems, and wearable devices such as smartwatches. They can also be various teaching aids (e.g., learning machines, early education machines), smart toys, portable robots, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, etc., and can also be devices with mobile office functions, smart home functions, audio-visual entertainment functions, or devices supporting smart travel. It should be understood that the embodiments of this application do not limit the specific technologies or device forms used in the electronic devices.

[0038] To better understand the embodiments of this application, the hardware structure of the terminal device in the embodiments of this application will be described first. For example, Figure 1 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application.

[0039] The terminal device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0040] Optionally, the sensor module 180 may include a pressure sensor 180A and a touch sensor 180B, etc.

[0041] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal device. In other embodiments of this application, the terminal device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0042] Processor 110 may include one or more processing units. For example, processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, etc. Different processing units may be independent devices or integrated into one or more processors. Processor 110 may also include memory for storing instructions and data.

[0043] USB port 130 is a USB standard compliant interface, which can be a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge terminal devices, and can also be used for data transfer between terminal devices and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other terminal devices, such as AR devices.

[0044] The charging management module 140 receives charging input from a charger, which can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also charge the terminal device via the power management module 141.

[0045] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, camera 193, display screen 194, audio module 170, and wireless communication module 160, etc. In some embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0046] Optionally, in some embodiments, the power management module 141 may also be referred to as a battery management unit (PMU). The PMU can be used to obtain the status information of the battery 142, such as the remaining power and temperature of the battery 142.

[0047] The wireless communication function of the terminal device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0048] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Antennas in terminal equipment can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0049] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G on terminal devices. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0050] The wireless communication module 160 can provide solutions for wireless communication applications on terminal devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), and other wireless communication technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0051] In some embodiments, antenna 1 of the terminal device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the terminal device to communicate with networks and other devices via wireless communication technology.

[0052] Camera 193 is used to capture still images or videos. In some embodiments, the terminal device may include one or N cameras 193, where N is a positive integer greater than 1.

[0053] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the terminal device may include one or N display screens 194, where N is a positive integer greater than 1.

[0054] Terminal devices can implement display functions through graphics processing units (GPUs), displays (194), and application processors. A GPU is a microprocessor for image processing, connecting the display (194) and the application processor. GPUs are used to perform mathematical and geometric calculations and for graphics rendering. GPUs can also be called display cores, visual processors, and display chips.

[0055] Terminal devices can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0056] Video codecs are used to compress or decompress digital video. Terminal devices can support one or more video codecs. This allows the terminal device to play or record video in various encoding formats, such as Moving Pictures Experts Group (MPEG) 1, MPEG2, MPEG3, and MPEG4. Furthermore, the terminal device can encapsulate and play audio and video data as well as screen recording data.

[0057] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal device. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0058] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area can store application programs (APPs) required for at least one function of the operating system, such as sound playback or image playback. The data storage area can store data created during the use of the terminal device (such as audio data, phonebook entries, etc.).

[0059] The terminal device can implement audio functions such as music playback and recording through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, and an application processor.

[0060] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Speaker 170A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Terminal devices can listen to music or make hands-free calls through speaker 170A. Receiver 170B, also called a "handpiece," is used to convert audio electrical signals into sound signals. When the terminal device answers a phone call or voice message, it can listen to the voice by bringing the receiver 170B close to the user's ear. Microphone 170C, also called a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. Headphone jack 170D is used to connect wired headphones.

[0061] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A may be disposed on display screen 194. When a touch operation is applied to display screen 194, the terminal device can detect the intensity of the touch operation based on pressure sensor 180A. The terminal device can also calculate the touch position based on the detection signal from pressure sensor 180A. Touch sensor 180B may be disposed on display screen 194, and the touch sensor 180B and display screen 194 together form a touch screen, also known as a "touchscreen". Touch sensor 180B is used to detect touch operations applied to or near it. Touch sensor 180B can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180B may also be disposed on the surface of the terminal device, in a different location than display screen 194.

[0062] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. The terminal device can receive button input and generate key signal inputs related to user settings and function control of the terminal device. Motor 391 can generate vibration prompts. Indicator 192 can be an indicator light, used to indicate charging status, power level changes, and also to indicate messages, missed calls, notifications, etc. Timer 196 can be used to record time information.

[0063] This invention does not limit the software architecture that the electronic device can adopt. Taking the Harmony operating system as an example, the software architecture of the electronic device 100 is described. In some implementations, such as... Figure 2 As shown, Harmony consists of four layers, from bottom to top: kernel layer, system basic service layer, framework layer, and application layer.

[0064] The Harmony system employs a multi-kernel design, optionally including the Linux kernel, the Harmony microkernel, and LiteOS. This design allows devices with varying capabilities to choose the appropriate system kernel. The kernel layer also includes a Kernel Abstraction Layer, which provides foundational kernel capabilities to other Harmony layers, such as process management, thread management, memory management, file system management, network management, and peripheral device management.

[0065] The system's basic service layer is the core capability set of the Harmony system, enabling it to provide application services through a framework layer in multi-device deployment scenarios. This layer may optionally include the following components:

[0066] The system's basic capability subsystems provide fundamental capabilities for the operation, scheduling, and migration of distributed applications across multiple devices within the Harmony system. These subsystems comprise a distributed soft bus, distributed data management and file management, distributed task scheduling, the Ark runtime, and distributed security and privacy protection. The Ark runtime provides runtime environments for multiple languages ​​(C / C++ / JavaScript) and basic system libraries. It also provides a runtime environment for Java programs statically generated using the Ark compiler (i.e., the parts of the application or framework layer developed using the Java language).

[0067] The basic software service subsystem suite provides common and general software services for the Harmony system, consisting of subsystems such as graphics and image processing, distributed media, distributed AI, multimodal input, MSDP & DV, event notification, telephony service, and distributed DFX. The basic software service subsystem suite can be customized according to the deployment environment of different device types, and each subsystem can be tailored to its functional granularity.

[0068] Enhanced Software Service Subsystem Assembly: This assembly provides Harmony systems with differentiated enhanced software services for various devices, comprising subsystems such as tablet business software, smart screen business software, in-vehicle business software, and IoT business software. The Enhanced Software Service Subsystem Assembly can be tailored to the deployment environment of different device types, at the subsystem level, and each subsystem can be further tailored at the functional level.

[0069] HarmonyDriver Framework (HDF) and Hardware Abstraction Adapter Layer (HAL) are the foundation for the open hardware ecosystem of the Harmony system. They provide hardware capability abstraction to the hardware at the top and development framework and runtime environment for various peripheral drivers at the bottom.

[0070] Hardware Service Subsystem Set: Provides common and adaptable hardware services for the Harmony system, consisting of hardware service subsystems such as general sensor, location, power, USB, and biometrics. The Hardware Service Subsystem Set can be tailored to the deployment environment of different device types, with each subsystem allowing for functional customization.

[0071] The proprietary hardware service subsystem provides differentiated hardware services for different devices within the Harmony system. Optional subsystems include proprietary hardware services for tablets, in-vehicle systems, wearables, and IoT devices. The proprietary hardware service subsystem can be tailored at the subsystem level, and each subsystem can be further customized at the functional level.

[0072] The framework layer provides Harmony system applications with user program frameworks and meta-capability frameworks in multiple languages ​​such as Java / C / C++ / JavaScript, as well as multi-language framework APIs for various software and hardware services.

[0073] The application layer includes system applications and third-party applications, which can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS. Applications in the Harmony system are built on the AA and FA foundations.

[0074] Electronic devices typically provide (also known as open) application programming interfaces (APIs) for applications to call. When an application calls an API, the electronic device needs to authenticate the application calling the API; the API is only allowed to be called if the authentication is successful.

[0075] The need for electronic devices to authenticate applications that call application programming interfaces (APIs) can also be described as: electronic devices verifying whether the caller of an API is authorized to call the API, electronic devices authenticating the caller of an API, or electronic devices determining whether an application has permission to call an API. In this embodiment, the application is also referred to as a client.

[0076] For example, service A in an electronic device can provide some application programming interfaces (APIs), and application B in the electronic device can call the APIs provided by service A. When application B calls the APIs, the electronic device needs to authenticate application B.

[0077] For example, the above application is a third-party application.

[0078] To facilitate understanding, the relationship between application programming interfaces (APIs), capabilities, and services is explained as follows: In this embodiment, a service can provide at least one capability, and a capability can provide at least one application programming interface (API). An API is used to provide a function. In other words, a service can be considered as a set of capabilities composed of capabilities, and a capability can be considered as a set of functions composed of application programming interfaces (APIs).

[0079] For example, service A in the above example can provide capability 1. The interfaces under capability 1 include application interface 1, application interface 2, and application interface 3. Application interface 1 corresponds to function 1, application interface 2 corresponds to function 2, and application interface 3 corresponds to function 3.

[0080] In some examples, services can be at the application level. For instance, a WeChat service can be broken down into capabilities, each exposing application programming interfaces (APIs) so that other applications can call these APIs to use the functionality provided by WeChat.

[0081] Currently, electronic devices mostly rely on cloud servers to authenticate users of application programming interfaces (APIs). For example, one existing method for authenticating API users includes:

[0082] 1) When a third-party application determines that it needs to call an application programming interface (API), it redirects to an authorization server in the cloud and requests user authorization. Once the user authorizes, the authorization server generates an authorization code and returns it to the third-party application.

[0083] 2) The third-party application sends the authorization code, client identifier (ID), and key to the authorization server. The authorization server verifies the authorization code, client ID, and key, and sends an access token to the client after successful verification.

[0084] The client identifier and key are sent to the third-party application by the authorization server when the third-party application registers with the authorization server.

[0085] 3) The client requests the service corresponding to the application programming interface (API) and sends the access token to the resource server. The resource server verifies the validity and permissions of the access token and decides whether to grant the client permission to schedule the API based on the result (i.e., decides whether to allow the client to schedule the API based on the result).

[0086] However, the above authentication methods have the following problems: First, if the authorization server malfunctions, third-party applications will be unable to call the application programming interface (API). Second, the authentication process requires interaction between the electronic device and the cloud-based authorization server, resulting in a long processing time. In other words, the authentication performance of current electronic devices is poor when authenticating API callers.

[0087] In view of this, this application provides a method for calling an application programming interface to improve authentication performance.

[0088] The following description, in conjunction with the accompanying drawings, illustrates the method for invoking an application programming interface (API) provided in this application. This method may also be referred to as the API authentication method.

[0089] refer to Figure 3 This application describes the method provided, which, for example, can be derived from... Figure 1 or Figure 2 The electronic device shown performs this action. Figure 3 As shown, the method includes:

[0090] S301: When the first application triggers a request to call the first application interface, obtain capability information.

[0091] In this embodiment, when the first application triggers a request to call the first application programming interface (API), the electronic device acquires capability information. Specifically, the capability information described in this embodiment is contained within the electronic device, and this capability information is used to indicate at least one capability that the first application can invoke. For example, the capability information includes at least one capability identifier, with each capability identifier indicating one capability, thus indicating at least one capability that the first application can invoke. The concept of a capability can be referred to the foregoing description, and will not be repeated here.

[0092] It should be noted that this embodiment does not limit which specific capabilities the first application can invoke; these can be determined by the developers of the first application during development. As an example, the first application may be a third-party application, and the capability information indicates that the first application can invoke at least one capability, including push notification capabilities, analytics capabilities, etc.

[0093] In one implementation, capability information can be included, for example, in a file of the first application. For instance, the capability information is included in the first application's profile file. This means that the capability information of the first application is written into the first application's profile file. For example, in implementation, when developing the first application, the developer can request the first application's profile file from the AppGallery Connect (AGC) and simultaneously indicate to the AGC at least one capability that the first application can invoke. Correspondingly, after receiving the request and indication, the AGC writes the capability information into the first application's profile file, which includes, for example, an identifier for each of the indicated at least one capability. Then, the developer of the first application downloads the profile file containing the capability information and packages the profile file into the first application.

[0094] Additionally, it should be noted that the profile file described above is merely an example and does not constitute a limitation of this embodiment. For example, capability information can also be included in other binary files of the first application. In this embodiment, the file containing capability information is also referred to as the first file.

[0095] In this embodiment, if a first application can invoke a capability, it is assumed that the first application can invoke all application programming interfaces (APIs) provided or developed by that capability. For example, the APIs opened by capability 1 include API 1, API 2, and API 3. API 1 corresponds to the login function, API 2 corresponds to the logout function, and API 3 corresponds to the password verification function. Therefore, if the capability information indicates that the first application can invoke capability 1, it means that the first application can invoke API 1, API 2, and API 3 under capability 1.

[0096] S302, if the first capability providing the first application interface is included in at least one capability indicated by the capability information, the first application is allowed to call the first application interface.

[0097] In this embodiment, the capability to provide the first application programming interface (API) is referred to as the first capability. In this embodiment, after the electronic device obtains the capability information of the first application, it determines whether to allow the first application to call the first API based on the first capability providing the API and the capability information of the first application.

[0098] In one implementation, when a request to invoke the first application interface is triggered by the first application, the first capability providing the first application interface indicates the identifier of the first capability to the electronic device, so that the electronic device can determine the first capability providing the first application interface.

[0099] Specifically, the electronic device determines whether to allow the first application to call the first application interface based on the first capability providing the first application interface and the capability information of the first application, including:

[0100] 1) If the first capability providing the first application interface is included in at least one capability indicated by the capability information, the first application is allowed to call the first application interface.

[0101] For example, the capability information of the first application includes at least one capability identifier that includes the identifier of the first capability, allowing the first application to call the first application programming interface.

[0102] The option to allow the first application to call the first application interface can also be replaced with any of the following: determining that the first application has permission to call the first application interface, determining that the first application has permission to access the first application interface, and allowing the first application to call the function corresponding to the first application interface.

[0103] 2) If the first capability that provides the first application interface is not included in at least one capability indicated by the capability information, the first application is not allowed to call the first application interface.

[0104] For example, if the capability information of the first application does not include the identifier of the first capability in at least one capability identifier, the first application is not allowed to call the first application interface.

[0105] The option of not allowing the first application to call the first application interface can also be replaced with any of the following: determining that the first application does not have permission to call the first application interface, determining that the first application does not have permission to access the first application interface, and not allowing the first application to call the function corresponding to the first application interface.

[0106] As can be seen, this technical solution, by including capability information in the electronic device to indicate at least one capability that the first application can invoke, enables the electronic device to determine whether the first application has permission to invoke the first application interface based on the capability information when the first application invokes the first application interface. This technical solution can authenticate whether the first application can invoke the first application interface without interaction between the electronic device and the cloud server. Therefore, it avoids the problems of the first application being unable to invoke the first application interface due to cloud server issues, resulting in low security, and the time-consuming authentication process via the cloud server. Thus, it improves the authentication performance of the first application in invoking the first application interface.

[0107] Below, taking the first file as the profile file as an example, combined with... Figure 4 and Figure 5 This describes a detailed implementation of an electronic device authentication method.

[0108] In development mode, such as Figure 4 As shown, it includes:

[0109] 1. Developers apply for a profile file (.p7b file) and a digital certificate file (.cer file) for their first application in AGC, and specify the capabilities they want to enable.

[0110] In this embodiment, if the first application has enabled a certain capability, it is considered that the first application has the permission to call the various application interfaces provided by the enabled capability.

[0111] For example, if the enabled capabilities include capability 1, capability 2, and capability 3, then the first application is considered to have the permission to call the various application interfaces under capability 1, the first application has the permission to call the various application interfaces under capability 2, and the first application has the permission to call the various application interfaces under capability 3.

[0112] 2. AGC writes the capability information into the profile file of the first application. The capability information includes at least one identifier, and one identifier corresponds to one enabled capability.

[0113] Taking the enabled capabilities as an example, including capability 1, capability 2, and capability 3, the capability information written in the profile file of the first application is as follows:

[0114] "Capability information for the first application":{

[0115] "Information for Identification Capability 1":{

[0116] },

[0117] "Information for Identification Capability 2":{

[0118] },

[0119] "Information for Identification Capability 3":{

[0120] }

[0121] }

[0122] 3. Developers download the digital certificate file and the profile file containing capability information.

[0123] This process can also be understood as AGC issuing a digital certificate file and a profile file containing capability information to the first application. The first application can store this digital certificate file and the profile file containing capability information in its installation package. Taking the Harmony system as an example, ... Figure 4As shown, the digital certificate file and the profile file containing capability information are stored in the first application's installation package HAP (Harmony Archive Package).

[0124] 4. Developers use digital certificate files and profile files to sign, compile, and package the first application, and then publish the packaged first application to the app store (APPGallery, AG).

[0125] It should be noted that the detailed process of using digital certificate files and profile files, participating in the signing of the first application, and compiling and packaging can be found in the descriptions in relevant technologies, and will not be repeated here.

[0126] Then, in runtime, such as Figure 5 As shown, it includes:

[0127] 1. Install the first application onto the electronic device.

[0128] During the installation of the first application on the electronic device, the first management module in the electronic device obtains the capability information from the profile file of the first application.

[0129] In one implementation, the first management module may be the Bundle Management Service (BMS) module.

[0130] In another implementation, the first management module may be a package manager service (PMS) module.

[0131] 2. The first application triggers a request to call the first application interface under the first capability.

[0132] 3. In response to the request, the first service providing the first capability triggers the invocation of the authentication module in the electronic device.

[0133] 4. The authentication module responds to the call of the first service and obtains the capability information of the first application's profile file from the first management module.

[0134] The authentication module obtains capability information from the profile file of the first application from the first management module; this is also referred to as the authentication module querying the capability information from the profile file of the first application from the first management module.

[0135] For example, such as Figure 5 As shown, the authentication module includes a capability query module. In response to the call of the first service, the capability query module obtains the capability information from the profile file of the first application from the first management module.

[0136] 5. The verification module in the authentication module verifies whether the first application has the permission to call the first application interface based on at least one capability indicated by the capability information returned by the first management module and the identifier of the first capability sent by the first service.

[0137] Optionally, the authentication module verifies whether the first application has permission to call the first application interface and then sends the verification result to the first service.

[0138] To make it easier to understand, the following is... Figure 4 and Figure 5 Based on the illustrated embodiment, taking application C as an example, this paper explains how an electronic device authenticates an application programming interface (API) requested by application C. In implementation, this includes:

[0139] 1) AGC provides a first interface to developers, through which developers of application C can enable the capabilities that application C wants to call.

[0140] For example, in response to a developer clicking on API management, AGC provides the developer with, for instance, the following: Figure 6 The first interface shown. Figure 6 As shown, the first interface displays services such as game services, video editing services, and weather services. Specifically, in this example, assume the game service can provide two capabilities, for example, game capability 1 and game capability 2.

[0141] like Figure 6 As shown, the first interface also displays settings controls, which developers can use to choose whether to enable the capability.

[0142] For example, when a developer sets the switch (i.e., the circular graphic) in the settings control to the right of Game Capability 1, it means that application C can call Capability 1.

[0143] For example, when a developer moves the toggle (circular icon) in the settings controls on the right side of the video editing service to the right, it means that application C can access all the capabilities of the video editing service. This can also be interpreted as: application C can access all the application programming interfaces (APIs) exposed by the video editing service.

[0144] For example, if the developer has not set the toggle (i.e., the circular icon) in the settings controls to the right of the weather service, it means that application C cannot access all the capabilities of the weather service. This can also be interpreted as application C not being able to access all the application programming interfaces (APIs) provided by the weather service.

[0145] 2) AGC writes capability information to the profile file of application C. This capability information includes field 1, which is used to identify game capability 1.

[0146] 3) The developer downloads the profile file of application C and uses the profile file to sign and package the application.

[0147] 4) The developer publishes the packaged application C to AG.

[0148] 5) The user downloads application C to the electronic device and installs it. During the installation process, the BMS in the electronic device parses the capability information in the profile file of application C.

[0149] 6) The user triggers the call to the application interface provided by game capability 1 while using application C.

[0150] 7) In response to the application interface of game capability 1 being called, the game service calls the authentication module.

[0151] 8) The authentication module calls the BMS to obtain the capabilities that application C has enabled. If it determines that game capability 1 is one of the capabilities that application C has enabled, the authentication module will then determine that the authentication is successful.

[0152] Optionally, the authentication module returns the authentication result to the game service.

[0153] Optionally, if a user triggers a call to the application programming interface (API) provided by the weather service while using application C, the weather service's API will be invoked, and the weather service will call the authentication module. Further, the authentication module will call the BMS to retrieve the capabilities already enabled by application C. If it determines that weather capabilities are not among the enabled capabilities of application C, the authentication module will then determine that authentication has failed.

[0154] Figure 7 This is a schematic diagram of the structure of an electronic device that calls an application programming interface (API) according to one embodiment of this application. Figure 7 As shown, the electronic device 700 includes a capability query module 701 and a verification module 702.

[0155] In one embodiment, the electronic device includes capability information indicating at least one capability that a first application can invoke. Specifically:

[0156] The capability query module 701 is used to obtain capability information in response to a request from the first application to call the first application interface;

[0157] The verification module 702 is configured to: allow the first application to call the first application interface if the first capability providing the first application interface is included in at least one capability indicated by the capability information.

[0158] In one possible implementation, the verification module 702 is further configured to: if the first capability providing the first application interface is not included in at least one capability indicated by the capability information, disallow the first application to call the first application interface.

[0159] In one possible implementation, the capability information is contained in the first file of the first application.

[0160] In one possible implementation, the first file is the Profile file of the first application.

[0161] In one possible implementation, the electronic device includes a first management module and a capability query module 701, specifically used to: obtain capability information from the first management module;

[0162] The first management module acquires capability information during the installation of the first application onto the electronic device.

[0163] Figure 8 This is a schematic diagram of the structure of an electronic device that calls an application programming interface, as provided in another embodiment of this application. Figure 8 As shown, the electronic device 800 may include a processor 801 and an interface circuit 802. The processor 801 and the interface circuit 802 are coupled to each other. It is understood that the interface circuit 802 may be a transceiver or an input / output interface. Optionally, the electronic device 800 may also include a memory 803 for storing instructions executed by the processor 801, or storing input data required by the processor 801 to execute instructions, or storing data generated after the processor 801 executes instructions.

[0164] Processor 801 can perform operations to determine whether the first application is allowed to call the first application programming interface. For example, the operations performed by the processor include:

[0165] If the first capability providing the first application interface is included in at least one capability indicated by the capability information, the first application is allowed to call the first application interface.

[0166] Alternatively, the operations performed by the processor may include:

[0167] If the first capability that provides the first application interface is not included in at least one capability indicated by the capability information, the first application is not allowed to call the first application interface.

[0168] In one possible implementation, the capability information is contained in the first file of the first application.

[0169] In one possible implementation, the first file is the Profile file of the first application.

[0170] It is understood that the processor in the embodiments of this application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0171] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device or terminal device. Alternatively, the processor and storage medium can exist as discrete components in the network device or terminal device.

[0172] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable electronic device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive.

[0173] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0174] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

Claims

1. A method for calling an application programming interface (API), characterized in that, Applied to an electronic device, the electronic device containing capability information indicating at least one capability that a first application can invoke, the method includes: When the first application triggers a request to call the first application interface, the capability information is obtained; If the first capability provided by the first application interface is included in at least one capability indicated by the capability information, the first application is allowed to call the first application interface.

2. The method according to claim 1, characterized in that, The method further includes: If the first capability that provides the first application interface is not included in the at least one capability indicated by the capability information, the first application is not allowed to call the first application interface.

3. The method according to claim 1 or 2, characterized in that, The capability information is contained in the first file of the first application.

4. The method according to claim 3, characterized in that, The first file is the Profile file of the first application.

5. The method according to claim 4, characterized in that, The electronic device includes a first management module, and the step of acquiring the capability information includes: The capability information is obtained from the first management module, wherein the first management module obtains the capability information during the process of installing the first application into the electronic device.

6. An electronic device, characterized in that, It includes one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer instructions that, when executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code for computer execution, the program code including instructions for implementing the method as described in any one of claims 1 to 5.

8. A chip, characterized in that, The chip stores a computer program, which, when executed by the chip, implements the method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes instructions for implementing the method as described in any one of claims 1 to 5.

Images