Method of invoking service, electronic device, and readable storage medium

Abstract

The application discloses a method for calling a service, an electronic device and a readable storage medium, and belongs to the technical field of terminals. The method comprises the following steps: in response to the starting of a service user, obtaining device manufacturer information of the electronic device, wherein the device manufacturer information is used for indicating whether the electronic device belongs to a target manufacturer, and the target manufacturer is a manufacturer providing a service required by the service user; determining a target service end from at least one candidate service end according to a service priority query order matched with the device manufacturer information, wherein the at least one candidate service end all provide the service required by the service user, and the at least one candidate service end has different existence forms in the electronic device; and in response to a service request of the service user, processing the service request through the target service end. The application enables each service user to call the same service end under the condition of meeting the service sharing condition, thereby realizing service or data sharing.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a method for invoking services, an electronic device, and a readable storage medium. Background Technology

[0002] Currently, business development generally includes two components: client and server. The server is used to provide the services required by service users (such as smart space, sports and health applications), while the client is used for service users to call, that is, service users call the server through the client.

[0003] Typically, electronic devices may contain multiple servers that provide the same service. For example, some servers may be integrated into the service user, while others may run independently in a separate process. In related technologies, service users usually default to using their own integrated server when connecting to a client.

[0004] However, in some scenarios, multiple service users may need to use the same service. If the server is called in the manner described above, these multiple service users will not be able to share services or data. Summary of the Invention

[0005] This application provides a method for invoking a service, an electronic device, and a readable storage medium, which can solve the problem that multiple service users cannot achieve service or data sharing. The technical solution is as follows:

[0006] Firstly, a method for invoking a service is provided, applied to an electronic device, the method comprising:

[0007] In response to a service user's initiation, the system retrieves the device manufacturer information of the electronic device. This information indicates whether the electronic device belongs to the target manufacturer, which provides the service required by the user. Subsequently, based on the service priority query order matching the device manufacturer information, a target server is determined from at least one candidate server. All at least one candidate server provides the required service, and these candidate servers exist in different forms within the electronic device. When a service user makes a service request, the request is processed through the determined target server. Thus, for any service user within the electronic device, this process invokes the server, ensuring that if a higher version or more compatible server exists, all service users can invoke that server. In other words, under service sharing conditions, all service users can invoke the same server, thereby achieving service or data sharing. Furthermore, determining the target server after the service user initiates the request, i.e., before requesting the service, allows for direct invocation during service requests, eliminating the need to determine the target server with each request, thus improving service invocation efficiency.

[0008] As an example of this application, when the device manufacturer information indicates that the electronic device belongs to the target manufacturer, the priority query order for services matching the device manufacturer information is: first candidate server, second candidate server; wherein, the first candidate server is a native server provided by the target manufacturer in the form of an APK, and the second candidate server is a server integrated into the service user's server in the form of a plugin. When the device manufacturer information indicates that the electronic device does not belong to the target manufacturer, the priority query order for services matching the device manufacturer information is: third candidate server, fourth candidate server, second candidate server; wherein, the third candidate server is a server in the form of an APK, and the APK containing the third candidate server is different from the APK containing the first candidate server, and the fourth candidate server is a server integrated into the third-party service user's server in the form of a plugin.

[0009] Thus, by determining the priority query order of services that match equipment manufacturer information, and then determining the target server based on the priority query order of services that match equipment manufacturer information, the accuracy and effectiveness of service calls can be improved.

[0010] As an example of this application, determining the target server from at least one candidate server based on the service priority query order matching device manufacturer information includes: determining the application identifier required for each query of the target server based on the service priority query order matching device manufacturer information. For each determined application identifier, the application information corresponding to the currently determined application identifier is queried from the application information list, which includes application information corresponding to each of multiple application identifiers. If the currently determined application identifier is not the application identifier of the service user, verification is performed based on the currently queried application information. If the verification passes, the server providing the service from the service provider corresponding to the currently determined application identifier is determined as the target server. If the verification fails, the process returns to the operation of determining the application identifier required for each query of the target server based on the service priority query order matching device manufacturer information.

[0011] Thus, since at least one candidate server differs depending on whether the electronic device belongs to the target manufacturer or not, the service priority query order differs. Determining the target server based on the service priority query order matching the device manufacturer information improves the accuracy and effectiveness of service calls.

[0012] As an example of this application, the application information in the application information list includes application version information. In this case, the implementation of verification based on the currently queried application information may include: comparing the application version information in the currently queried application information with the application version information provided in the client used by the service user. If the application version information in the currently queried application information is higher than the application version information provided in the client used by the service user, the verification is deemed to have passed. If the application version information in the currently queried application information is lower than the application version information provided in the client used by the service user, the verification is deemed to have failed.

[0013] In this way, by comparing application version information for verification, it can be determined whether the version of the service provider is higher than the version required by the service user, thereby determining whether the service provided by the server in the service provider can meet the needs of the service user and ensuring the validity of the service call.

[0014] As an example of this application, the application information in the application information list includes a server identifier. In this case, the implementation of verification based on the currently queried application information may include: if the currently queried application information includes a first server identifier of the service provider, binding the service user's client to the server corresponding to the first server identifier; obtaining the server interface version information of the server corresponding to the first server identifier through the service user's client; if the obtained server interface version information is higher than the server interface version information provided in the client used by the service user, the verification is deemed successful; if the obtained server interface version information is lower than the server interface version information provided in the client used by the service user, the verification is deemed unsuccessful.

[0015] In this way, by binding the service user's client to the server, obtaining the server's interface version information, and determining whether the verification passes based on the server's interface version information, the server's version is guaranteed to be higher than the version supported by the service user's client, thereby ensuring the validity of the service call.

[0016] As an example of this application, device manufacturer information indicates that the electronic device belongs to the target manufacturer. In this case, determining the application identifier required for each query of the target server based on the service priority query order matching the device manufacturer information may include: determining the application identifiers required for each query of the target server as a first application identifier and a second application identifier based on the service priority query order matching the device manufacturer information, wherein the first application identifier is the identifier of the APK where the first candidate server is located, and the second application identifier is the identifier of the APK where the second candidate server is located.

[0017] In this way, within the manufacturer's own electronic devices, the target server is determined according to the aforementioned service priority query order, enabling different service users to call the same server as much as possible, thereby achieving service or data sharing. Furthermore, even if the service sharing conditions are not met, service users can still use their own server, ensuring the independence of each service user.

[0018] As an example of this application, the device manufacturer information indicates that the electronic device does not belong to the target manufacturer. In this case, the implementation of determining the application identifiers required for each query of the target server based on the service priority query order matching the device manufacturer information may include: determining the application identifiers required for each query of the target server as a third application identifier, a fourth application identifier, and a second application identifier, based on the service priority query order matching the device manufacturer information, where the third application identifier is the identifier of the APK containing the third candidate server, and the fourth application identifier is the identifier of the APK containing the fourth candidate server.

[0019] In this way, in electronic devices from other manufacturers, the target server is determined according to the service priority query order mentioned above, enabling different service users to call the same server as much as possible, thereby achieving service or data sharing. Furthermore, even if the service sharing conditions are not met, service users can still use their own server, ensuring the independence of each service user.

[0020] As an example of this application, the fourth application identifier is determined from the system configuration file, or it is determined from the system property information. By setting the fourth application identifier in the preset settings, the fourth application identifier can be queried regardless of which manufacturer's electronic device the server is integrated into. This allows the server integrated into the third-party service user to be queried based on the fourth application identifier, thereby ensuring the applicability of the service invocation method.

[0021] In a second aspect, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of invoking services as described in the first aspect.

[0022] Thirdly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the method of invoking services described in the first aspect.

[0023] Fourthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the method of invoking services described in the first aspect.

[0024] The technical effects achieved by the second, third, and fourth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating a component related to a functional characteristic according to an exemplary embodiment;

[0026] Figure 2 This is a schematic diagram illustrating the form in which a server exists in an electronic device of a target manufacturer, according to an exemplary embodiment.

[0027] Figure 3 This is a schematic diagram illustrating the form in which a server exists in an electronic device from another manufacturer, according to an exemplary embodiment.

[0028] Figure 4This is a schematic diagram illustrating the form of server presence in an electronic device from another manufacturer, according to another exemplary embodiment.

[0029] Figure 5 This is a schematic diagram illustrating the form of server presence in an electronic device from another manufacturer, according to another exemplary embodiment.

[0030] Figure 6 This is a schematic diagram illustrating several forms of server and client existence in an electronic device according to an exemplary embodiment;

[0031] Figure 7 This is a schematic diagram illustrating an application scenario according to an exemplary embodiment;

[0032] Figure 8 This is a schematic diagram illustrating an application scenario according to another exemplary embodiment;

[0033] Figure 9 This is a schematic diagram illustrating a software system of an electronic device according to an exemplary embodiment;

[0034] Figure 10 This is a flowchart illustrating a method for invoking a service according to an exemplary embodiment;

[0035] Figure 11 This is a schematic diagram illustrating an application scenario according to an exemplary embodiment;

[0036] Figure 12 This is a flowchart illustrating a method for invoking a service according to another exemplary embodiment;

[0037] Figure 13 This is a flowchart illustrating a method for invoking a service according to another exemplary embodiment;

[0038] Figure 14 This is a flowchart illustrating a method for invoking a service according to another exemplary embodiment;

[0039] Figure 15 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

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

[0041] It should be understood that "multiple" as mentioned in this application refers to two or more. In the description of this application, unless otherwise stated, " / " indicates "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, to facilitate a clear description of the technical solutions of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0042] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0043] To facilitate understanding, the terms and vocabulary used in the embodiments of this application will be briefly explained first.

[0044] Service users are the parties that request a service, or those requesting a feature, such as proximity discovery. Service users are typically, but are not limited to, applications that interact with the user on an electronic device. Examples include applications for fitness and health, smart spaces, vehicle connectivity, video, games, and navigation. A service user corresponds to an Android package (APK). Once installed on an electronic device, the APK becomes a service user. In some examples, service users may also be called feature users, service consumers, or feature consumers.

[0045] Service provider: This is the party that provides the service, or the party that provides the functionality, such as the proximity discovery feature. A service provider also corresponds to an APK. In some examples, the service provider may also be called a feature provider, service provider, or feature provider, etc.

[0046] Source: refers to installing or pre-installing the APK provided by the manufacturer on other manufacturers' electronic devices.

[0047] See Figure 1 The implementation of functional features generally includes a server and a client. The server is the specific implementation of the functional features provided by the service provider; for example, the server is a Service. The client is the interface provided by the server (i.e., Service) for service users to call. For example, the client is a software development kit (SDK) interface, as shown below.

[0048] See Figure 2 In some target manufacturers' (such as Honor, which can be referred to as "R manufacturer") electronic devices, the server-side (i.e., the Service) provided by the target manufacturer itself is usually integrated into the service provider's APK (i.e., the native APK provided by the target manufacturer), while the client is integrated into the service user's APK. These two APKs can communicate through the Android Binder mechanism. That is, during business implementation, one APK can call another APK through the Android Binder mechanism, where the calling APK is the service user and the called APK is the service provider.

[0049] In some scenarios, the target manufacturer's service users need to support normal operation on other manufacturers' electronic devices through installation or pre-installation. For example, it might be necessary to install a specific app from Honor on another manufacturer's electronic device. As mentioned earlier, this situation can be referred to as the outgoing end. To ensure that the service user can use the service normally after going out, the server used by the service user needs to be supported on other manufacturers' electronic devices. Since the service user only partially depends on the service provider (i.e., only depends on the server in the service provider), the service provider's APK (i.e., the native APK) is usually not included in the outgoing end of the service user's device. For one possible implementation, please refer to [link to relevant documentation]. Figure 3 This allows the service providers that the service users depend on to also be integrated into the service users' end, following the service users' output.

[0050] Of course, in some examples, the service provider's functional characteristics may also be extended to other manufacturers' electronic devices as basic features to provide capabilities externally, that is, for use by multiple service users in other manufacturers' electronic devices. In other words, functional characteristics can be extended to other manufacturers' electronic devices for use. As an example of this application, the extension forms of functional characteristics typically include the following two:

[0051] Format 1: Delivered as an APK.

[0052] Please see Figure 4As an example, the server-side component from the service provider can be exported as an APK, meaning it can be pre-installed on other manufacturers' electronic devices. The exported APK is largely consistent with the unexported APK (i.e., the native APK) in terms of logical framework and form. Typically, the exported APK may add or remove some functionality from the unexported APK. It can be understood that the unexported APK is the native APK provided by the target manufacturer, while the exported APK is a modified version of the native APK. Differences between the exported and unexported APKs generally include: different ranges of supported functions, performance differences, differences in special adaptations, or different operating environments. Due to these differences, the exported APK usually also differs from the unexported APK in its binary information, mainly in the application identifier and signing method. The application identifier identifies an APK (or service user), such as an application name or application ID. The signature distinguishes different applications with the same package name, preventing application forgery and replacement.

[0053] Form 2: Output as a plugin.

[0054] For example, the plugin can be an AAR (Android archive) or a JAR (Java archive).

[0055] Please see Figure 5 As an example, the server-side component from the service provider can be integrated into the APK of a third-party service user in the form of an AAR or JAR file, allowing it to be routed to electronic devices of other manufacturers (such as manufacturer X). The third-party service user is not a service user provided by the target manufacturer; for example, the third-party service user might be a service user provided by manufacturer X. In this case, the server-side component depends on the runtime environment of the third-party service user; for instance, searching for the server-side component requires using the application identifier of the third-party service user.

[0056] In one possible implementation, vendor X's electronic device can encapsulate functional features that are output as plug-ins, that is, within the third-party service user... Figure 5 The service provider (in plug-in form) shown is encapsulated so that various service users of Vendor X can use the outgoing terminal's functionalities through the encapsulated SDK interface, thus ensuring the uniformity of service calls. In another possible implementation, Vendor X's electronic devices may not encapsulate the outgoing terminal's functionalities in plug-in form, that is, directly... Figure 5The service provider shown is integrated into a third-party service user. In this case, the service user of vendor X accesses the server through the SDK interface of the outgoing end.

[0057] It should be noted that, Figure 5 In this context, the upper-layer service APK refers to an APK installed or pre-installed on electronic devices from other manufacturers that does not belong to the target manufacturer. For example, the upper-layer service APK might be an application provided by manufacturer X. In one possible implementation, if manufacturer X's electronic device encapsulates the functional characteristics of the outgoing end, the upper-layer service APK can integrate the encapsulated SDK interface; that is, the integrated SDK interface is provided by manufacturer X. In another possible implementation, if manufacturer X's electronic device does not encapsulate the functional characteristics of the outgoing end, the upper-layer service APK may integrate an SDK interface corresponding to the server-side of the outgoing end; that is, the SDK interface corresponding to the server-side of the outgoing end is provided by the target manufacturer. Alternatively, the upper-layer service APK may not integrate an SDK interface; for example, it can directly use the SDK interface of the outgoing end's functional characteristics when requesting a service.

[0058] As described above, whether it's the target manufacturer's electronic devices or other manufacturers' electronic devices, the following issues may occur: Figure 6 The scenario depicted in Figure (a) or (b) illustrates a situation where a certain functional feature may have multiple servers on an electronic device, and these servers may exist in different forms. For example:

[0059] See Figure 6 In Figure (a), on the electronic device provided by the target manufacturer, a certain functional feature may exist in the following forms of server: (1) a server existing in the form of a native APK; (2) a server integrated as a plugin into the service user of the output terminal, which also integrates a client for calling the server, and the service user of the output terminal is the service user provided by the target manufacturer. In addition, as Figure 6 As shown in Figure (a), in electronic devices provided by the target manufacturer, some service users may also integrate a client for calling the server, and the service user does not include the server.

[0060] See Figure 6 In Figure (b), on electronic devices provided by other manufacturers, a certain functional feature may exist in the following forms of server-side: (1) a server-side that originates as an APK; (2) a server-side that is integrated into a third-party service user as a plugin, and the corresponding client is also integrated into that third-party service user; (3) a server-side that is integrated into the originating service user as a plugin, and the corresponding client is also integrated into the originating service user. Additionally, as... Figure 6As shown in Figure (b), on electronic devices provided by other manufacturers, there may also be an outgoing service user and an upper-layer business APK, and the outgoing service user integrates a client corresponding to the server.

[0061] For ease of description and understanding, please refer to Figure 6 Next, we will differentiate between the various server-side components in the above scenarios.

[0062] (1) The server that provides functional features in the service provider that is pre-installed or installed on the target manufacturer's electronic device can be denoted as SVC1. The application identifier used when accessing the server SVC1 through mechanisms such as Binder can be denoted as PKG1. PKG1 is used to identify the APK where the server SVC1 is located.

[0063] (2) For a server that provides functional features to other manufacturers' electronic devices in the form of an APK, it can be denoted as SVC2. The application identifier used when accessing the server SVC2 through mechanisms such as Binder can be denoted as PKG2. PKG2 is used to identify the APK where the server SVC2 is located.

[0064] (3) For a server that provides functional features by being integrated into a third-party service user in the form of a plugin, it can be referred to as SVC3. The application identifier used when accessing the server SVC3 through mechanisms such as Binder can be referred to as PKG3. PKG3 is used to identify the APK where the server SVC3 is located.

[0065] (4) For a server that provides functional features by being integrated into the service user provided by the target manufacturer in the form of a plug-in, it can be denoted as SVC4. The application identifier used when accessing the server SVC4 through mechanisms such as Binder can be denoted as PKG4. PKG4 is used to identify the APK where the server SVC4 is located.

[0066] Therefore, SVC1 and SVC2 can provide capabilities externally, meaning they can be used by multiple service users within the electronic device. SVC1 and SVC2 are typically located at the lower layers of the electronic device (such as the application framework layer). Additionally, SVC3 can also provide capabilities externally as a basic feature, meaning it can also be used by multiple service users within the electronic device. However, since SVC3 is integrated into third-party service users, it is usually located at the upper layers of the electronic device (such as the application layer). SVC4 is a server-side component used by the service user itself. Therefore, from the perspective of the system hierarchy of the electronic device, the importance or core potential of the aforementioned server-side components is: SVC1 = SVC2 > SVC3 > SVC4. That is, SVC1 and SVC2 are equally important and have the highest importance, while SVC4 has the lowest importance.

[0067] As described above, SVC1 and SVC2 typically do not coexist in the same electronic device. For example, SVC1 may exist in the target manufacturer's electronic device, while SVC2 may exist in other manufacturers' electronic devices. Furthermore, in some embodiments, SVC3 generally does not coexist with SVC1 or SVC2 in the same electronic device. However, in other embodiments, SVC3 may coexist with SVC1 or SVC2 in the same electronic device; this application does not limit this.

[0068] In some scenarios, multiple service users may need to share capabilities or data, such as sharing configuration information, databases, or in-memory data. To address this, embodiments of this application provide a service invocation method. This method adaptively accesses services when multiple servers exist within an electronic device, enabling multiple service users to utilize the same server as much as possible to achieve service or data sharing through this single server. Furthermore, even if the conditions for service or data sharing are not met, each service user's own access mechanism remains unaffected, thus ensuring the independence of each service user.

[0069] To facilitate understanding, the following sections will introduce several exemplary application scenarios involved in the embodiments of this application.

[0070] In one example, see Figure 7 The electronic device includes two applications: Smart Space and Sports Health. Sports Health integrates a server-side application for proximity detection. The underlying layer of the electronic device also provides a server-side application for proximity detection. During Smart Space operation, when a user triggers the electronic device to scan for other nearby devices, Smart Space invokes the underlying server-side application. The server-side application performs the proximity detection function, i.e., scanning. When a blood pressure monitor is near the electronic device, Smart Space can detect the blood pressure monitor through the underlying server-side application and trigger the electronic device to establish a communication connection with the blood pressure monitor. Thus, Smart Space can interact with the blood pressure monitor through the established communication connection. Subsequently, during Sports Health operation, when a user triggers the electronic device to detect other devices through Sports Health, Sports Health also invokes the underlying server-side application. Since the underlying server-side application has already detected the blood pressure monitor, it no longer scans but directly notifies Sports Health that the blood pressure monitor has been detected and data transmission can begin directly. Thus, Sports Health can interact with the blood pressure monitor through the established communication connection.

[0071] See another example. Figure 8The electronic device contains two applications: a navigation application and a file-sharing application. The navigation application integrates a server-side mechanism enabling proximity detection. The underlying layer of the electronic device also provides a server-side mechanism, similarly enabling proximity detection. In one possible scenario, the electronic device needs to send navigation information to a vehicle's infotainment system. To do this, the user can trigger the navigation application to use proximity detection to find the vehicle's infotainment system. At this point, the navigation application calls the underlying server-side mechanism of the electronic device. The server-side mechanism executes proximity detection and, upon finding the vehicle's infotainment system, triggers a connection between the electronic device and the vehicle's infotainment system. The navigation application can then send navigation information to the vehicle's infotainment system through this established connection. Subsequently, when the file-sharing application on the electronic device wants to share files with the vehicle's infotainment system, it also needs to call the underlying server-side mechanism. In this case, because the underlying proximity detection mechanism has already detected the vehicle's infotainment system, it no longer needs to perform scanning and connection operations. Instead, it can directly instruct the file-sharing application to send the files. Thus, the file-sharing application can send the files to be shared to the vehicle's infotainment system through the established connection.

[0072] Therefore, in this embodiment, when multiple applications in an electronic device need to use the proximity discovery feature, they do not call their own servers, but instead uniformly call the underlying server of the electronic device, thereby achieving service sharing. Thus, once a connection has been established through the proximity discovery feature, when other applications also use the proximity discovery feature, the electronic device no longer needs to scan, which can reduce the power consumption of the electronic device to some extent.

[0073] It should be noted that the above application scenarios are merely exemplary and do not limit the application of the service invocation method provided in this application embodiment. For example, the service invocation method provided in this application embodiment can also be applied to adaptive access scenarios of multiple similar functional modules, etc.

[0074] It should also be noted that the electronic devices involved in the embodiments of this application may be, but are not limited to, mobile phones, action cameras (GoPro), digital cameras, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, in-vehicle devices, ultra-mobile personal computers (UMPC), netbooks, cellular phones, personal digital assistants (PDAs), augmented reality (AR) / virtual reality (VR) devices, and the embodiments of this application do not limit them.

[0075] The software system of an electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses the layered architecture Android system as an example to illustrate the software system of an electronic device. Figure 9 This is a block diagram of a software system for an electronic device provided in an embodiment of this application. See also... Figure 9 A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime, the system layer, and the kernel layer.

[0076] The application layer can include a series of application packages. For example... Figure 9 As shown, the application package may include applications such as smart space, sports and health, vehicle connectivity, navigation, and file sharing, which are also referred to as service users in this embodiment. In some examples, the service user integrates an SDK interface, that is, a client, for the service provider to call. Additionally, the service user may also integrate a business module, which is used to monitor the triggering of business processes. In one possible implementation, the service user may also integrate a server-side component (…). Figure 9 (Not shown in the image).

[0077] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions. For example... Figure 9 As shown, the application framework layer can include service providers (i.e., APKs), where the server-side component can run. Additionally, the application framework layer can also include the Activity Manager Service (AMS). AMS is a system service in Android that runs within the system process and is primarily responsible for managing the application lifecycle, task stack management, and interactions between applications.

[0078] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0079] The service invocation method provided in the embodiments of this application will be described next.

[0080] As an example of this application, in order to ensure that multiple service users who need to use the same service call the same server as much as possible, the electronic device can specify the service priority query order of the aforementioned servers, so that the service user can determine the target server to use from multiple servers according to the service priority query order. For example, the service priority query order can be:

[0081] (1) On the target manufacturer's electronic equipment, queries can be performed in the order of PKG1>PKG3=PKG4, and the service user corresponding to PKG4 does not access the server in the service user corresponding to PKG3.

[0082] (2) On other manufacturers' electronic devices, you can search in the order of PKG2>PKG3>PKG4.

[0083] Based on this, the next step is to combine Figure 10 This application provides a detailed description of the method for invoking services provided in the embodiments of this application. This method is illustrative and not limiting; it applies to the methods described above. Figure 9 For the electronic devices shown, please refer to Figure 10 This method may include some or all of the following:

[0084] S1001: In response to the service user's initiation, obtain the device manufacturer information of the electronic device, and determine whether the electronic device belongs to the target manufacturer based on the device manufacturer information.

[0085] Device manufacturer information is used to indicate whether an electronic device belongs to the target manufacturer. As mentioned earlier, the target manufacturer is the provider of the service needed by the service user. For example, if the target manufacturer is manufacturer R, it is the manufacturer that provides the original service.

[0086] The service user can be any application installed or pre-installed on an electronic device. In one possibility, the service user is triggered by the user. For example, if the service user is a fitness tracker, when the user needs to use the fitness tracker, they can click the fitness tracker application icon on the electronic device, and the electronic device will launch the fitness tracker in response to the user's action. In another possibility, the service user is a persistent process that starts after the electronic device is powered on and the system boots up.

[0087] After a service user starts up, it usually needs to use the service during operation, which means it needs to call the server. Since there may be multiple servers in an electronic device, in order to facilitate the direct call of the server when the service user needs to use the service, the electronic device can determine one of the multiple servers as the target server after the service user starts up. The target server is used by the service user to call to execute the functional features when the service needs to use the service.

[0088] Because the priority of service queries differs depending on whether the electronic device belongs to the target manufacturer or not, the electronic device queries the manufacturer information after the service user initiates the service to determine whether it belongs to the target manufacturer. As an example of this application, the electronic device can obtain manufacturer information from the system.

[0089] If the electronic device is determined to belong to the target manufacturer based on the equipment manufacturer information, proceed to step S1002; otherwise, if the electronic device is determined not to belong to the target manufacturer based on the manufacturer equipment information, proceed to step S1008.

[0090] S1002: Query the application information list to see if there is application information corresponding to PKG1. The application information list includes multiple application information.

[0091] As mentioned above, PKG1 is the application identifier used when accessing the server SVC1. The server SVC1 is the server that provides functional features, which is pre-installed or installed on the target manufacturer's electronic device by the service provider.

[0092] As an example of this application, PKG1 can be pre-configured in the SDK interface used by the service user. That is, the electronic device uses the PKG1 provided in the SDK interface of the service user to query the application information list to see if the application information corresponding to PKG1 exists.

[0093] The application information list can be managed by the Application Management System (AMS) within the electronic device. As an example, and not a limitation, the application information list includes application information for all applications on the electronic device; that is, the application information list includes multiple application information entries. Application information may include application version information, application identifier, and server identifier. Furthermore, application information may also include signatures, user identification (UID), etc.

[0094] A server identifier is used to uniquely identify a server. An application information may include one server identifier, which means that the service provider corresponding to the application information only provides one type of server. Alternatively, an application information may include multiple server identifiers, each of which is used to identify a server. In this case, it means that the service provider corresponding to the application information provides multiple types of servers, each of which is used to implement different services. For example, some servers are used to implement proximity discovery functions, while others are used to implement location functions, etc.

[0095] UIDs can be used to distinguish different applications and can be used to prevent applications from being forged and replaced.

[0096] According to the service priority query order specified by the electronic device (i.e., PKG1 > PKG3 = PKG4), when querying the target server in the target manufacturer's electronic device, PKG1 is used first for querying, that is, to check if there is a callable service provider corresponding to PKG1. To do this, the electronic device queries the application information list to see if there is application information corresponding to PKG1. In one example, the electronic device can iterate through multiple application information entries in the application information list to check if there is application information corresponding to PKG1.

[0097] If the application information corresponding to PKG1 exists in the application information list, it means that the electronic device has a server SVC1. In this case, the electronic device proceeds to step S1003. Otherwise, if the application information corresponding to PKG1 does not exist in the application information list, it means that the electronic device does not have a server SVC1. In this case, the electronic device proceeds to step S1006.

[0098] S1003: Verify based on the application information corresponding to PKG1 to determine whether the verification passes.

[0099] In one example, verification can be performed based on the application version information carried in the application information. For instance, the specific verification method may include comparing the application version information in the application information corresponding to PKG1 with the application version information in the SDK interface used by the service user. If the application version information in the application information corresponding to PKG1 is higher than the application version information in the SDK interface used by the service user, the verification is deemed successful. Otherwise, if the application version information in the application information corresponding to PKG1 is lower than the application version information in the SDK interface used by the service user, the verification is deemed unsuccessful.

[0100] The application version information in the service user's SDK interface can be preset, indicating which version of the service provider the service user supports. If the application version information in the application information corresponding to PKG1 is higher than the application version information in the service user's SDK interface, it indicates that the service provider's application version is higher. In this case, it can be determined that the service provided by the server-side of the service provider can meet the service user's needs, and therefore the verification result is passed. Otherwise, if the application version information in the application information corresponding to PKG1 is lower than the application version information in the service user's SDK interface, it indicates that the service provider's application version is lower. In this case, it can be determined that the service provided by the server-side of the service provider cannot meet the service user's needs, and therefore the verification result is failed.

[0101] In another example, verification can also be performed based on the server-side interface version information. For instance, if the application information in the application information list includes a server identifier, the verification process can include: determining whether SVC1 exists in the application information corresponding to PKG1. If SVC1 exists in the application information corresponding to PKG1, then the service user's SDK interface is bound to the server corresponding to SVC1. For example, the service user's SDK interface can send a binding request to the service provider corresponding to PKG1, carrying SVC1 in the binding request, so that the service provider corresponding to PKG1 binds the server-side SVC1 to the service user's SDK interface. Then, the service user's SDK interface obtains the server-side interface version information of SVC1 from the bound server. If the obtained server-side interface version information is higher than the pre-set server-side interface version information in the service user's SDK interface, the verification is considered successful; if the obtained server-side interface version information is lower than the pre-set server-side interface version information in the service user's SDK interface, the verification is considered unsuccessful.

[0102] In one example, the service user's SDK interface can retrieve its server-side interface version information from SVC1 using an interface version information retrieval function. If the server-side interface version information provided by SVC1 is higher than the pre-set server-side interface version information in the service user's SDK interface, it indicates that the version of SVC1 is higher. In this case, it can be determined that the service provided by SVC1 meets the service user's needs, and therefore the verification result is passed. Otherwise, if the server-side interface version information provided by SVC1 is lower than the pre-set server-side interface version information in the service user's SDK interface, it indicates that the version of SVC1 is lower. In this case, it can be determined that the service provided by SVC1 cannot meet the service user's needs, and therefore the verification result is failed.

[0103] Of course, if the server identifier in the application information corresponding to PKG1 does not include SVC1, it indicates that there is no server SVC1 in the service provider corresponding to PKG1, and the verification will fail in this case.

[0104] It should be noted that this embodiment of the application uses the inclusion of a server identifier in the application information as an example. In another example, the application information may not include a server identifier. In this case, the service user's SDK interface cannot determine whether the service provider corresponding to PKG1 provides a server-side SVC1. In this situation, if the application information corresponding to PKG1 is confirmed to exist, the service user's SDK interface can also send a binding request to the service user corresponding to PKG1. The binding request can carry SVC1 to attempt to bind with the server-side SVC1. If the service user corresponding to PKG1 has a server-side SVC1, it will bind with the service user's SDK interface. Afterward, the service user's SDK interface can obtain the server-side interface version information from the server-side SVC1 and perform verification. If the service user corresponding to PKG1 does not have a server-side SVC1, the service user corresponding to PKG1 will return a binding failure message, indicating that the verification has failed.

[0105] As an optional implementation, after verification, the electronic device can unbind the service user's SDK interface from the bound server to avoid prolonged binding to the server when not in use, thereby avoiding the occupation of service resources.

[0106] It should also be noted that the above explanation uses the example of first binding to the server to obtain the server-side interface version information. In another example, the application version information corresponding to PKG1 may also include server-side interface version information; that is, a field in the application version information can carry server-side interface version information, such as the server-side interface version information corresponding to SVC1. In this case, server binding is not required during the verification process; the electronic device can directly perform verification based on the server-side interface version information included in the application version information and the server-side interface version information provided in the service user's SDK interface.

[0107] As an example of this application, if the application information also includes a signature, the signature can be verified before performing the above verification operation to determine whether the service provider corresponding to PKG1 is reliable. If the signature verification passes, the above verification operation is then performed to improve the security of service calls.

[0108] Similarly, if the application information also includes a UID, the UID can be verified before performing the above verification operation to determine whether the service provider corresponding to PKG1 is reliable. If the UID verification passes, the above verification operation can then be performed to improve the security of service calls.

[0109] In one possible implementation, the application information also includes a signature and a UID. Before performing the above verification operation, the electronic device verifies the signature and the UID respectively. If both the signature and the UID pass the verification, the above verification operation is then performed to improve the security of service calls.

[0110] As an optional implementation, the verification process can begin with verification based on the application version information (see previous section for details). If the application version verification passes, then verification based on the server-side interface version information is performed (see previous section for details). If the server-side interface version verification passes, the verification result is considered successful; otherwise, if the server-side interface version verification fails, the verification result is considered unsuccessful. Conversely, if the application version verification fails, the verification result is considered unsuccessful. This multi-layered verification approach improves the effectiveness of the verification process.

[0111] If the verification passes, it indicates that the server SVC1 in the electronic device can provide services that meet the needs of the service user. At this time, server SVC1 is identified as the target server, and the electronic device proceeds to step S1004. If the verification fails, it indicates that the server SVC1 in the electronic device cannot provide services that meet the needs of the service user. At this time, the electronic device proceeds to step S1006.

[0112] S1004: Service query results. Service query results are used to indicate the target server that the service user can call.

[0113] In one example, the service query result includes the application identifier of the APK containing the identified target server. For instance, if the application information verification based on PKG1 passes, the service query result includes PKG1. Furthermore, it may also include the server identifier of the target server; for example, if the target server is server SVC1, the service query result will also include SVC1.

[0114] It should be noted that this explanation assumes the application information verification based on PKG1 passes. In another example, if the application information verification based on other PKGs passes, the service query result will include the identifiers of those other applications. For instance, if the application information verification based on PKG1 fails, but the service user integrates server-side SVC4, the service query result will include PKG4, and may further include SVC4. In other words, the stored service query result includes information related to the ultimately determined target server.

[0115] S1005: In response to a service request from a service user, the target server is invoked based on the service query results.

[0116] After storing the service query results, when a user triggers a service user to call the target server, the service user can determine the relevant information of the target server based on the service query results, thereby determining which server to call to execute the requested service. For example, if the service query results include PKG1, it can be determined that the target server to be called is server SVC1. Then, the service user can call the target server, such as server SVC1, through the SDK interface.

[0117] In one example, assuming the service user is sports and health, and the target server provides a proximity discovery function, please refer to [link to example]. Figure 11 In Figure (a), when the application interface U1 for sports and health is displayed, the application interface U1 includes an interface switching option 1101. When the user clicks the interface switching option 1101, in response to the user's trigger operation on the interface switching option 1101, the electronic device displays the application interface U2 for sports and health, as shown in Figure (a). Figure 11 As shown in Figure (b), the application interface U2 includes an "Add Device" item 1102, which is triggered by the user. In response to the user's triggering of the "Add Device" item 1102, the service user, based on the service query results, sends a service request to the target server via the SDK interface to invoke the target server to perform a scan. For example, the electronic device may display something like this during the scan process. Figure 11 The interface shown in Figure (c) scans for other devices in the vicinity to discover them, enabling the establishment of communication connections with these devices and subsequent data exchange.

[0118] It should be noted that the above explanation assumes the electronic device has not previously performed the proximity discovery function. In another example, if the electronic device has already performed the proximity discovery function—that is, if other service users on the electronic device have invoked the target server to perform the proximity discovery function—then when a service user invokes the target server, the electronic device will no longer perform a scanning function. Instead, it will directly indicate to the service user that a communication connection has been established and data transmission can proceed directly, thereby achieving service sharing.

[0119] S1006: Check whether the service user has integrated a server-side component.

[0120] As mentioned earlier, the service user may have integrated a server. If the application information verification based on PKG1 fails, or if the electronic device does not have the application information corresponding to PKG1, the electronic device can query whether the service user itself has integrated a server. In one example, the electronic device can query whether the SDK interface used by the service user contains indication information indicating that it has integrated a server. If such indication information exists, it is determined that the service user has integrated a server; if it does not exist, it is determined that the service user has not integrated a server.

[0121] If no server exists among the service users, proceed to step S1007. Otherwise, if a server exists among the service users, i.e., server SVC4 exists, then execute step S1004. In this case, the stored service query result includes the application identifier of the service user, such as PKG4, and may further include SVC4.

[0122] S1007: The server is inaccessible.

[0123] Since the service user corresponding to PKG4 does not access the server in the service user corresponding to PKG3, if the application information corresponding to PKG1 does not exist or the verification based on the application information corresponding to PKG1 fails, and there is no server in the service user, it means that there is no server available for the service user to access. In this case, the electronic device can report the service query result to the service user as the service is inaccessible, so that the service user can know that the service is inaccessible.

[0124] As an example, when a service is inaccessible, a pop-up window can be displayed in the application interface of the service user when the service user calls the server, displaying a message indicating that the service is inaccessible, in order to inform the user.

[0125] S1008: Query the application information list to see if there is application information corresponding to PKG2.

[0126] As mentioned above, PKG2 is the application identifier used when accessing the server SVC2. The server SVC2 is an APK sent to the server in other manufacturers' electronic devices; that is, PKG2 is the application identifier of the outgoing APK, and the outgoing APK includes the server SVC2.

[0127] PKG2 can also be pre-configured in the SDK interface used by the service user. That is, if the electronic device is determined not to belong to the target manufacturer based on the device manufacturer information, the electronic device uses the PKG2 provided in the service user's SDK interface to query the application information list to see if there is application information corresponding to PKG2, thus checking if the electronic device contains an outgoing APK that includes the server. In one example, the electronic device can iterate through multiple application information entries in the application information list to check if there is application information corresponding to PKG2.

[0128] If the application information corresponding to PKG2 exists in the application information list, it means that the electronic device has an outgoing APK, that is, a server-side SVC2 exists. In this case, the electronic device proceeds to step S1009. Otherwise, if the application information corresponding to PKG2 does not exist in the application information list, it means that the electronic device does not have an outgoing APK, that is, a server-side SVC2 does not exist. In this case, the electronic device proceeds to step S1010.

[0129] S1009: Verify based on the application information corresponding to PKG2 and determine whether the verification passes.

[0130] The implementation method for verification based on the application information corresponding to PKG2 can be found in the specific implementation of verification based on the application information corresponding to PKG1 in S1003, which will not be elaborated here.

[0131] If the application information verification based on PKG2 passes, it indicates that the electronic device contains a server SVC2, and that the server SVC2 can provide services that meet the needs of the service user. In this case, the target server is the server SVC2, and the electronic device executes step S1004. At this time, the service query result may include PKG2, and may further include SVC2. Otherwise, if the application information verification based on PKG2 fails, it indicates that the electronic device contains a server SVC2, but the server SVC2 cannot provide services that meet the needs of the service user. In this case, the electronic device proceeds to step S1010.

[0132] S1010: Obtain PKG3, which is used to access the server-side SVC3.

[0133] Since the server-side SVC3 is integrated into the third-party service user, its operating environment depends on that user. For example, the third-party service user that the server-side SVC3 relies on may differ across different manufacturers' (excluding the target manufacturer's) electronic devices. For instance, on manufacturer B's electronic device, the server-side SVC3 might rely on APK1, while on manufacturer C's electronic device, it might rely on APK2. In other words, the third-party service user may vary across different manufacturers' (excluding the target manufacturer's) electronic devices, and even across different devices from the same manufacturer. Therefore, to ensure overall consistency, PKG3 can be configured in a pre-set configuration item within the electronic device's system. When PKG3 is needed, the electronic device can then query it from this pre-set configuration item, facilitating the retrieval of the corresponding application information from the application information list.

[0134] As an example, and not a limitation, this default configuration item can be a system configuration file, such as a JSON file. Alternatively, it can be system property information (such as Android's Property mechanism). For example, if the default configuration item is ro.vendor.magicringpkgname and PKG3 is com.xiaomi.pkgname, then the electronic device can set PKG3 to ro.vendor.magicringpkgname = com.xiaomi.pkgname.

[0135] Optionally, when setting this preset configuration item, the electronic device can also encrypt the preset configuration item and then store the encryption key used for encryption. Thus, when the PKG3 is needed, the stored encryption key can be used to decrypt the preset configuration item to obtain the PKG3. This ensures the security of data storage.

[0136] S1011: Query the application information list to see if there is application information corresponding to PKG3.

[0137] In one example, the electronic device iterates through multiple application information entries in the application information list to check if the application information entry corresponding to PKG3 exists in the application information list.

[0138] In one possible scenario, the application information list contains application information corresponding to PKG3. This indicates that the electronic device has a server-side SVC3 corresponding to PKG3. In this case, the electronic device proceeds to step S1012. In another possible scenario, the application information list does not contain application information corresponding to PKG3. This indicates that the electronic device does not have a server-side SVC3 corresponding to PKG3. In this case, the electronic device executes step S1006.

[0139] S1012: Verify based on the application information corresponding to PKG3 and determine whether the verification passes.

[0140] For the implementation of verification based on the application information corresponding to PKG3, please refer to the specific implementation of verification based on the application information corresponding to PKG1 in S1003. It will not be described in detail here.

[0141] If the application information verification based on PKG3 passes, it indicates that the electronic device contains a server-side SVC3 and the services provided by the server-side SVC3 can meet the needs of the service user. Therefore, the electronic device executes step S1004. At this time, the service query result can include PKG3, and further, it can also include SVC3. Otherwise, if the application information verification based on PKG3 fails, it indicates that although the electronic device contains a server-side SVC3, the services provided by the server-side SVC3 cannot meet the needs of the service user. Therefore, the electronic device executes step S1006, that is, it queries whether the service user has integrated a server-side SVC4.

[0142] As an example of this application, after the service user closes the service, the relevant data of the target server used this time can be deleted, such as the service query results and execution results, so that if the target server sends changes (such as version updates), the latest version of the server can be used next time.

[0143] In this embodiment, in response to a service user's initiation, the device manufacturer information of the electronic device is obtained. This device manufacturer information indicates whether the electronic device belongs to the target manufacturer, which is the provider of the service required by the service user. Then, based on the service priority query order matching the device manufacturer information, the target server is determined from multiple servers. When the service user requests to invoke the service, the service request is processed through the target server. Thus, for any service user within the electronic device, the server is invoked according to this process. This ensures that if a server with a higher version or stronger service compatibility exists, all service users can invoke that server. In other words, under the condition of service sharing, all service users can invoke the same server, thereby achieving service or data sharing.

[0144] according to Figure 10 As can be seen from the illustrated embodiments, determining the specific implementation of the target server depends on whether the electronic device belongs to the target manufacturer. For ease of understanding, the following two embodiments will describe the service invocation process in two scenarios: one where the electronic device belongs to the target manufacturer and the other where it does not.

[0145] Please see Figure 12 , Figure 12 This is a flowchart illustrating a method for invoking a service according to another exemplary embodiment. Here, the electronic device belongs to the target manufacturer, and the method comprises the above-described... Figure 9 Taking the execution of the electronic device shown as an example, which is achieved through the interaction of multiple modules, the method can mainly include the following implementation steps.

[0146] S1201: In response to the service user starting the service, AMS notifies the service user's business module.

[0147] As an example of this application, taking the sports and health service as an example, when a user clicks the sports and health application icon on an electronic device, AMS detects the user's click operation, and then AMS notifies the business module.

[0148] It should be noted that this embodiment of the application illustrates the example of AMS being able to detect the service user's startup. In another example, the electronic device can also detect the service user's startup through other modules, and then those other modules notify the business module; this embodiment of the application does not limit this approach.

[0149] S1202: The service user's business module sends an initialization request to the service user's client.

[0150] In other words, after receiving the startup notification from the service user, the business module sends an initialization request to the service user's SDK interface to request the SDK interface to initialize the runtime environment.

[0151] S1203: In response to the initialization request, the client sends a device information retrieval request to AMS.

[0152] S1204: AMS sends device manufacturer information to the client.

[0153] Upon receiving the initialization request, the client retrieves the device manufacturer information from the electronic device's system. As an example, and not a limitation, the client retrieves the device manufacturer information from the AMS (Automatic Management System). For instance, the AMS might provide an interface for retrieving device manufacturer information; thus, the client can send a device information retrieval request to the AMS by calling this interface to obtain the device manufacturer information.

[0154] S1205: The client determines that the electronic device belongs to the target manufacturer based on the device manufacturer information.

[0155] After obtaining the device manufacturer information, the client can determine whether the electronic device belongs to the target manufacturer based on this information. This application embodiment uses the example of the electronic device belonging to the target manufacturer for illustration. For a specific implementation of determining whether the electronic device does not belong to the target manufacturer based on the device manufacturer information, please refer to [link to implementation details]. Figure 13 The example shown.

[0156] S1206: The client sends the first query request to AMS, which carries PKG1.

[0157] The first query request is used to request the application information corresponding to PKG1.

[0158] PKG1 is pre-configured in the client.

[0159] As an example of this application, AMS provides an interface for requesting and querying application information. When a client needs to query application information, it can call this interface to retrieve the required application information from AMS.

[0160] S1207: In response to the first query request, AMS sends the application information corresponding to PKG1 to the client.

[0161] As an example, the AMS manages an application information list, which includes application information for all applications in the electronic device. Upon receiving a first query request, the AMS can iterate through the application information list to check if application information corresponding to PKG1 exists. This application uses the example of application information corresponding to PKG1 existing for illustration.

[0162] It should be noted that this embodiment of the application illustrates the example of sending a first query request to AMS when it is necessary to query the application information corresponding to PKG1. In an optional implementation, the client can also obtain an application information list from AMS after receiving a notification from AMS that the service user has started. Thus, when querying the application information corresponding to PKG1, the client can query from the obtained application information list, for example, by iterating through it. It should be noted that in this implementation, there is no strict order of execution between the client's operation of obtaining the application information list and the operation of obtaining the device manufacturer information. In one example, these two operations can be executed in parallel, that is, the device manufacturer information is obtained simultaneously with the application information list.

[0163] S1208: The client performs verification based on the application information corresponding to PKG1.

[0164] For the specific implementation of the verification, please refer to Figure 10 Step S1003 in the illustrated embodiment.

[0165] If the application information verification based on PKG1 passes, the client executes operation S1209. Otherwise, if the application information verification based on PKG1 fails, the client executes operation S1210.

[0166] S1209: The client stores the query results of the first service, which include PKG1.

[0167] In other words, if the application information verification based on PKG1 passes, it means that there is a server SVC1 corresponding to PKG1 in the electronic device, and the service provided by the server SVC1 can meet the needs of the service user. Therefore, the client can record PKG1 locally so that when the service is needed later, the server SVC1 can be determined based on the first service query result and the server SVC1 can be called to implement the required service.

[0168] S1210: The client stores the query results of the second service, which include PKG4.

[0169] In other words, if the application information verification based on PKG1 fails, it means that there is a server SVC1 corresponding to PKG1 in the electronic device, but the service provided by the server SVC1 cannot meet the needs of the service user. Therefore, the client can record PKG4 locally so that when the service is needed later, the server SVC4 can be determined based on the second service query result, and the server SVC4 can be called to implement the required service.

[0170] It should be noted that the above explanation assumes that the application information corresponding to PKG1 exists in the application information list. In another possible scenario, if the application information corresponding to PKG1 does not exist in the application information list, AMS will send a query result to the client indicating that no application information corresponding to PKG1 exists. In this case, the client will also store the query result from the second service.

[0171] It should also be noted that this embodiment is illustrated using an example where the service user has integrated the SVC4 server. In another example, if the service user has not integrated the SVC4 server, the client will determine that the service is inaccessible.

[0172] The above process initializes the runtime environment after the service user starts up. Afterwards, if the service user calls the server, the electronic device can access it based on the initialization results (i.e., the stored service query results), as detailed below:

[0173] S1211: In response to a user's business-triggered operation on the service user, AMS notifies the service user's business module.

[0174] For example, see Figure 11 In Figure (b), the user clicks the "Add Device" item in the application interface U2 of the service user, triggering the service activation operation. In this way, AMS can detect the service activation operation and notify the service user's business module.

[0175] It should be noted that this application embodiment uses the AMS module to detect the user's business trigger operation on the service user as an example for illustration. In another example, it can also be detected by other modules in the electronic device, and this application embodiment does not limit this.

[0176] S1212: The business module calls the client of the service user.

[0177] S1213: The client queries the service query results, which include either the first service query results or the second service query results.

[0178] As mentioned earlier, if the application information verification based on PKG1 passes, the client stores the first service query result. Otherwise, if the application information verification based on PKG1 fails or the application information corresponding to PKG1 does not exist, and if the service user integrates server-side SVC4, the client stores the second service query result. Therefore, the service query result queried by the client may be either the first service query result or the second service query result.

[0179] If the service query result is the first service query result, proceed to step S1214. Otherwise, if the service query result is the second service query result, proceed to step S1219.

[0180] S1214: The client sends a binding request to the service provider corresponding to PKG1, and the binding request carries SVC1.

[0181] The binding request is used to request binding with the server-side SVC1.

[0182] S1215: The service provider corresponding to PKG1 binds the client to the server SVC1.

[0183] It should be noted that this embodiment of the application is based on the example where the client and the server SVC1 of the service user corresponding to PKG1 have not been bound before. In one possible implementation, the client and the server SVC1 of the service provider corresponding to PKG1 have been bound before, for example, in a scenario where they were bound during the verification based on the server interface version information and have not been unbound. In this case, the client directly enters the following operation S1216, that is, it does not need to perform the binding operation again.

[0184] S1216: The client sends a service request to the service provider corresponding to PKG1.

[0185] S1217: The service provider corresponding to PKG1 processes the service request without having processed the service request before.

[0186] In one example, during the service provider's operation, if the service request has not been processed before, it is processed, for example, by performing a device scan. If the service request has been processed before, for example, if the server has an execution result for the service request, the execution result can be obtained and sent to the client.

[0187] In another example, during the service provider's operation, if the service request has not been processed within a preset time period, then the service request is processed. If the service request has been processed within the preset time period, then the execution result of the service request is obtained and sent to the client.

[0188] The preset duration can be set according to needs. By setting a preset duration, the shared service or data can be the result of the most recent execution, improving the effectiveness of service provision.

[0189] S1218: The service provider corresponding to PKG1 returns the execution result to the client.

[0190] After the service provider corresponding to PKG1 returns the execution result to the client, it proceeds to the following step S1223.

[0191] S1219: Bind the client to the server SVC4.

[0192] S1220: The client sends a service request to the server SVC4.

[0193] S1221: Server-side SVC4 processes service requests.

[0194] S1222: The server-side SVC4 sends the execution result to the client.

[0195] S1223: The client sends the execution result to the business module.

[0196] This enables service invocation. Furthermore, as long as a server with strong compatibility or a high-version version exists, service calls from multiple service users utilizing this feature can be aggregated onto that server, meaning multiple service users can call the same server, achieving service and data sharing. Of course, even if service sharing is not satisfied, the access mechanisms of each service user will not be affected; they can still use their own server, thus ensuring the independence of each service user.

[0197] In this embodiment, in response to a service user's initiation, the device manufacturer information of the electronic device is obtained. This device manufacturer information indicates whether the electronic device belongs to the target manufacturer, which provides the service required by the service user. Then, based on the service priority query order matching the device manufacturer information, the target server is determined from multiple servers. When the service user requests to invoke the service, the service request is processed through the target server. Thus, for any service user within the electronic device, the server is invoked according to this process. This ensures that if a server with a higher version or stronger service compatibility exists, all service users can invoke that server. In other words, under the condition of service sharing, all service users can invoke the same server, thereby achieving service or data sharing.

[0198] Please see Figure 13 , Figure 13 This is a flowchart illustrating a method for invoking a service according to another exemplary embodiment. Here, the electronic device is not from the target manufacturer, and the method is as described above. Figure 9 Taking the execution of the electronic device shown as an example, which is achieved through the interaction of multiple modules, the method can mainly include the following implementation steps.

[0199] S1301: In response to the service user starting the service, AMS notifies the business module.

[0200] S1302: The business module sends an initialization request to the client of the service user.

[0201] S1303: In response to the initialization request, the client sends a device information retrieval request to AMS.

[0202] S1304: AMS sends device manufacturer information to the client.

[0203] For details on the implementation of steps S1301 to S1304, please refer to [link / reference]. Figure 12 Steps S1201 to S1204 in the process.

[0204] S1305: The client determines that the electronic device does not belong to the target manufacturer based on the device manufacturer information.

[0205] S1306: The client sends a second query request to AMS, which carries PKG2.

[0206] The second query request is used to request the application information corresponding to PKG2.

[0207] PKG2 is pre-configured in the client.

[0208] S1307: In response to the second query request, AMS sends the application information corresponding to PKG2 to the client.

[0209] As an example, after receiving the first query request, AMS can iterate through the application information list to check if there is application information corresponding to PKG2.

[0210] This application embodiment is illustrated using the example of application information corresponding to PKG2. If there is no application information corresponding to PKG2, the query result returned by AMS to the client is that there is no application information corresponding to PKG2. In this case, the following operation S1310 is performed.

[0211] S1308: The client performs verification based on the application information corresponding to PKG2.

[0212] For the specific implementation of the verification, please refer to Figure 10 Step S1003 in the illustrated embodiment.

[0213] If the application information verification based on PKG2 passes, the client executes operation S1309. Otherwise, if the application information verification based on PKG2 fails, the client executes operation S1310.

[0214] S1309: The client stores the query results of the third service, which include PKG2.

[0215] In other words, if the application information verification based on PKG2 passes, it means that there is a server SVC2 corresponding to PKG2 in the electronic device, and the service provided by the server SVC2 can meet the needs of the service user. Therefore, the client can record PKG2 locally so that when the service is needed later, the server SVC2 can be determined based on the query result of the third service, and the server SVC2 can be called to implement the required service.

[0216] S1310: The client sends an application information retrieval request to AMS to request PKG3.

[0217] S1311: AMS sends PKG3 to the client.

[0218] In other words, if the application information verification based on PKG2 fails, or if the application information corresponding to PKG2 does not exist, the client obtains PKG3. For details on the implementation of obtaining PKG3, please refer to [link to relevant documentation]. Figure 10 Step S1010 in the illustrated embodiment.

[0219] S1312: The client sends a third query request to AMS, which carries PKG3.

[0220] The third query request is used to request the application information corresponding to PKG3.

[0221] S1313: In response to the third query request, AMS sends the application information corresponding to PKG3 to the client.

[0222] It should be noted that this embodiment is illustrated using the example of application information corresponding to PKG3 existing. In another possible scenario, the electronic device does not have application information corresponding to PKG3. In this case, AMS reports to the client that there is no application information corresponding to PKG3, and the client then proceeds to step S1316.

[0223] Similarly, this embodiment of the application illustrates the example of sending a corresponding query request to AMS when it is necessary to query the application information corresponding to a certain PKG (such as PKG2 or PKG3). In an optional implementation, the client can also obtain an application information list from AMS after receiving a notification from AMS that the service user has started. In this way, when it is necessary to query the application information corresponding to a certain PKG, the client can query from the obtained application information list.

[0224] S1314: The client performs verification based on the application information corresponding to PKG3.

[0225] For details on the client-side verification based on the application information corresponding to PKG3, please refer to [link / reference]. Figure 10 Step S1003 in the illustrated embodiment.

[0226] If the application information verification based on PKG3 passes, the client executes operation S1315. Otherwise, if the application information verification based on PKG1 fails, the client executes operation S1316.

[0227] S1315: The client stores the query results of the fourth service, which include PKG3.

[0228] If the application information verification based on PKG3 passes, it indicates that the electronic device has a server SVC3 corresponding to PKG3, and the service provided by the server SVC3 can meet the needs of the service user. Therefore, the client can record PKG3 locally so that when the service is needed later, the server SVC3 can be determined based on the query result of the fourth service, and the server SVC3 can be called to implement the required service.

[0229] It should be noted that this embodiment of the application is illustrated using the example of application information corresponding to PKG3 existing in the application information list. If application information corresponding to PKG3 does not exist in the application information list, the following operation S1316 is performed.

[0230] S1316: The client stores the query results of the second service, which include PKG4.

[0231] If the application information verification based on PKG3 fails, it indicates that the electronic device contains a server-side SVC3 corresponding to PKG3, but the service provided by the server-side SVC3 cannot meet the needs of the service user; or if there is no application information corresponding to PKG3, it indicates that there is no server-side SVC3 corresponding to PKG3. Therefore, the client can record PKG4 locally so that when the service is needed later, it can determine the server-side SVC4 based on the second service query result and call the server-side SVC4 to implement the required service.

[0232] It should be noted that the embodiments in this application are illustrated using an example where the service user has integrated the server-side SVC4. In another example, if the service user has not integrated the server-side SVC4, the client will determine that the service is inaccessible.

[0233] The initialization process is now complete. Afterwards, if a service user calls the server, the electronic device can access it based on the initialization results. See below for details:

[0234] S1317: When triggered by a business function, the business module calls the client.

[0235] For its specific implementation, please refer to Figure 12 Steps S1211 to S1212 in the illustrated embodiment.

[0236] S1318: Client query service query results, which include third service query results, fourth service query results, or second service query results.

[0237] If the service query result is the third service query result, proceed to step S1319. Otherwise, if the service query result is the fourth service query result, proceed to step S1324. Otherwise, if the service query result is the second service query result, proceed to step S1329.

[0238] S1319: The client sends a binding request to the service provider corresponding to PKG2, and the binding request carries SVC2.

[0239] The binding request is used to request binding with the server-side SVC2.

[0240] S1320: The service provider corresponding to PKG2 binds the client to the server SVC2.

[0241] Similarly, if the client and the server SVC2 are already bound, for example, if they are bound during the verification based on the server interface version information and have not been unbound, the client will directly enter the following 1321 operation, that is, there is no need to perform the binding operation again.

[0242] S1321: The client sends a service request to the server SVC2.

[0243] S1322: The server-side SVC2 processes the service request if it has determined that the service request has not been processed before.

[0244] For a detailed implementation, please refer to [link / reference]. Figure 12 S1217 in the illustrated embodiment.

[0245] S1323: The server-side SVC2 returns the execution result to the client.

[0246] After returning the execution result, proceed to the following step S1333.

[0247] S1324: The client sends a binding request to the service user corresponding to PKG3, and the binding request carries SVC3.

[0248] S1325: The service user corresponding to PKG3 binds the server-side SVC3 to the client.

[0249] S1326: The client sends a service request to the server SVC3.

[0250] S1327: The server-side SVC3 processes service requests if it determines that no service request has been processed before.

[0251] S1328: The server-side SVC3 returns the execution result to the client.

[0252] After returning the execution result, proceed to the following step S1333.

[0253] S1329: The client binds to the server-side SVC4.

[0254] S1330: The client sends a service request to the server SVC4.

[0255] S1331: Server-side SVC4 processes service requests.

[0256] S1332: The server-side SVC4 sends the execution result to the client.

[0257] S1333: The client sends the execution result to the business module.

[0258] In this embodiment, in response to a service user's initiation, the device manufacturer information of the electronic device is obtained. This device manufacturer information indicates whether the electronic device belongs to the target manufacturer, which provides the service required by the service user. Then, based on the service priority query order matching the device manufacturer information, the target server is determined from multiple servers. When the service user requests to invoke the service, the service request is processed through the target server. Thus, for any service user within the electronic device, the server is invoked according to this process. This ensures that if a server with a higher version or stronger service compatibility exists, all service users can invoke that server. In other words, under the condition of service sharing, all service users can invoke the same server, thereby achieving service or data sharing.

[0259] Please see Figure 14 , Figure 14 This is a flowchart illustrating a method for invoking a service according to another exemplary embodiment. As an example and not a limitation, this method applies to the above. Figure 9 The electronic device shown may include some or all of the following:

[0260] S1401: In response to the service user's initiation, obtain the device manufacturer information of the electronic device. The device manufacturer information is used to indicate whether the electronic device belongs to the target manufacturer, which is the manufacturer that provides the service required by the service user.

[0261] For its specific implementation, please refer to the above. Figure 10 Step S1001 in the illustrated embodiment.

[0262] S1402: Based on the service priority query order matching the equipment manufacturer information, determine the target server from at least one candidate server. At least one candidate server provides the service required by the service user. At least one candidate server exists in a different form in the electronic device.

[0263] As an example of this application, when the device manufacturer information indicates that the electronic device belongs to the target manufacturer, the priority query order for services matching the device manufacturer information is: first candidate server, second candidate server; wherein, the first candidate server is a native server provided by the target manufacturer in the form of an APK (native APK), and the second candidate server is a server integrated into the service user as a plugin, and the service user is usually provided by the target manufacturer. For example, the first candidate server is server SVC1, and the second candidate server is server SVC4.

[0264] As an example of this application, when the device manufacturer information indicates that the electronic device does not belong to the target manufacturer, the priority query order for services matching the device manufacturer information is: third candidate server, fourth candidate server, and second candidate server; wherein, the third candidate server is a server existing in the form of an APK, and the APK containing the third candidate server (the modified APK) is different from the APK containing the first candidate server; the fourth candidate server is a server integrated into the third-party service user as a plugin. For example, the third candidate server is server SVC2, and the fourth candidate server is server SVC3.

[0265] Because at least one candidate server differs depending on whether the electronic device belongs to the target manufacturer or not, the service priority query order differs. Therefore, determining the target server based on the service priority query order matching the device manufacturer information can improve the accuracy and effectiveness of service calls.

[0266] In one example, the specific implementation of S1402 includes: determining the application identifier (i.e., PKG) required for each query of the target server based on the service priority query order matching the device manufacturer information. For each determined application identifier, the application information corresponding to the currently determined application identifier is queried from the application information list, which includes application information corresponding to each of multiple application identifiers. If the currently determined application identifier is not the application identifier of the service user, verification is performed based on the currently queried application information. If the verification passes, the server providing the service from the service provider corresponding to the currently determined application identifier is identified as the target server. If the verification fails, the process returns to the operation of determining the application identifier required for each query of the target server based on the service priority query order matching the device manufacturer information.

[0267] It should be noted that, in the case where the currently determined application identifier is the application identifier of a third-party service user, the service provider corresponding to this application identifier is integrated into the third-party application user in the form of a plugin.

[0268] For details on the verification based on the currently retrieved application information, please refer to [link / reference]. Figure 10 S1003 in the illustrated embodiment.

[0269] If the currently identified application identifier is the application identifier of the service user, it is possible to query whether the service user has integrated the server. If the server has been integrated, then the server is identified as the target server, meaning that no further verification is required.

[0270] In this way, based on the service priority query order matching the equipment manufacturer's information, each candidate server in the electronic device is queried one by one to determine the server with strong compatibility or high priority, and then the server is invoked. This allows various service users in the electronic device to use the same server, instead of each using its own integrated server. This achieves service or data sharing.

[0271] As an example of this application, when the device manufacturer information indicates that the electronic device belongs to the target manufacturer, the application identifiers required for each query of the target server are determined according to the service priority query order matching the device manufacturer information. This includes determining the application identifiers required for each query of the target server as a first application identifier and a second application identifier, based on the service priority query order matching the device manufacturer information. The first application identifier is the identifier of the APK containing the first candidate server, and the second application identifier is the identifier of the APK containing the second candidate server. For example, the first application identifier is PKG1, and the second application identifier is PKG4.

[0272] In this way, within the manufacturer's own electronic devices, the target server is determined according to the aforementioned service priority query order, enabling different service users to call the same server as much as possible, thereby achieving service or data sharing. Furthermore, even if the service sharing conditions are not met, service users can still use their own server, ensuring the independence of each service user.

[0273] As an example of this application, when the device manufacturer information indicates that the electronic device does not belong to the target manufacturer, the application identifiers required for each query of the target server are determined according to the service priority query order matching the device manufacturer information. This includes: determining the application identifiers required for each query of the target server as a third application identifier, a fourth application identifier, and a second application identifier, based on the service priority query order matching the device manufacturer information. The third application identifier is the identifier of the APK containing the third candidate server, and the fourth application identifier is the identifier of the APK containing the fourth candidate server. For example, the third application identifier is PKG2, and the fourth application identifier is PKG3.

[0274] In this way, in electronic devices from other manufacturers, the target server is determined according to the service priority query order mentioned above, enabling different service users to call the same server as much as possible, thereby achieving service or data sharing. Furthermore, even if the service sharing conditions are not met, service users can still use their own server, ensuring the independence of each service user.

[0275] As an example of this application, the fourth application identifier is determined from the system configuration file or from system property information. Thus, by setting the fourth application identifier in the preset settings, the fourth application identifier can be retrieved regardless of which manufacturer's electronic device the server is integrated into. This allows the server integrated into the third-party service user to be located based on the fourth application identifier, thereby ensuring the applicability of the service invocation method.

[0276] S1403: In response to a service request from a service user, the service request is processed by the target server.

[0277] For its specific implementation, please refer to Figure 10 S1005 in the illustrated embodiment.

[0278] In this embodiment, in response to a service user's initiation, the device manufacturer information of the electronic device is obtained. This device manufacturer information indicates whether the electronic device belongs to the target manufacturer, which provides the service required by the service user. Then, based on the service priority query order matching the device manufacturer information, the target server is determined from multiple servers. When the service user requests to invoke the service, the service request is processed through the target server. Thus, for any service user within the electronic device, the server is invoked according to this process. This ensures that if a server with a higher version or stronger service compatibility exists, all service users can invoke that server. In other words, under the condition of service sharing, all service users can invoke the same server, thereby achieving service or data sharing.

[0279] It is also worth noting that the concept of calling services provided in this application embodiment can also be applied to software engineering or system engineering with similar characteristics (such as server access priority control).

[0280] Figure 15 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. See also... Figure 15The electronic device 100 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. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer 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, etc.

[0281] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 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.

[0282] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0283] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0284] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from this memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

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

[0286] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0287] The power management module 141 is used to connect 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, display 194, camera 193, and wireless communication module 160, etc.

[0288] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

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

[0290] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is an integer greater than 1.

[0291] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

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

[0293] Internal memory 121 can be used to store computer-executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121, such as executing the service invocation methods described in the above embodiments. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created by electronic device 100 during use (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0294] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D and application processor.

[0295] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch display." Touch sensor 180K detects touch operations applied to or near it. Touch sensor 180K 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 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0296] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0297] The above-described embodiments are optional embodiments provided by this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the technical scope disclosed in this application should be included within the protection scope of this application.

Claims

1. A method for invoking a service, characterized in that, Applied to electronic devices, the method includes: In response to the service user's initiation, the device manufacturer information of the electronic device is obtained. The device manufacturer information is used to indicate whether the electronic device belongs to the target manufacturer, which is the manufacturer that provides the service required by the service user. Based on the service priority query order matching the device manufacturer information, a target server is determined from at least one candidate server. All at least one candidate server provides the service required by the service user. The at least one candidate server exists in different forms in the electronic device. In response to a service request from the service user, the service request is processed by the target server. Wherein, when the device manufacturer information indicates that the electronic device belongs to the target manufacturer, the priority query order for services matching the device manufacturer information is: first candidate server, second candidate server; wherein, the first candidate server is a native server provided by the target manufacturer in the form of an APK, and the second candidate server is a server integrated into the service user in the form of a plugin; If the device manufacturer information indicates that the electronic device does not belong to the target manufacturer, the priority query order for services matching the device manufacturer information is: third candidate server, fourth candidate server, and second candidate server; wherein, the third candidate server is a server existing in the form of an APK, and the APK containing the third candidate server is different from the APK containing the first candidate server, and the fourth candidate server is a server integrated into the third-party service user in the form of a plugin.

2. The method as described in claim 1, characterized in that, The step of determining the target server from at least one candidate server based on the service priority query order matching the equipment manufacturer information includes: Based on the service priority query order that matches the device manufacturer information, determine the application identifier that needs to be used for each query of the target server; For each application identifier determined, the application information corresponding to the currently determined application identifier is queried from the application information list, which includes the application information corresponding to each application identifier among multiple application identifiers; If the currently determined application identifier is not the application identifier of the service user, verification is performed based on the currently queried application information; If the verification passes, the server providing the service among the service providers corresponding to the currently determined application identifier will be identified as the target server. If the verification fails, the process returns to the operation of determining the application identifier required for each query of the target server based on the service priority query order that matches the device manufacturer information.

3. The method as described in claim 2, characterized in that, The application information in the application information list includes application version information; The step of verifying the application identifier based on the currently queried application information when the currently determined application identifier is not the application identifier of the service user includes: If the currently determined application identifier is not the application identifier of the service user, the application version information in the currently queried application information is compared with the application version information provided in the client used by the service user. If the application version information in the currently queried application information is higher than the application version information provided in the client used by the service user, then the verification is confirmed to be successful. If the application version information found in the current query is lower than the application version information provided in the client used by the service user, then the verification is determined to have failed.

4. The method as described in claim 2, characterized in that, The application information in the application information list includes the server identifier; The step of verifying the application identifier based on the currently queried application information when the currently determined application identifier is not the application identifier of the service user includes: If the currently determined application identifier is not the application identifier of the service user, and if the currently queried application information includes the first server identifier of the server providing the service, then the client of the service user will be bound to the server corresponding to the first server identifier. The server interface version information of the server corresponding to the first server identifier is obtained through the client of the service user; If the obtained server-side interface version information is higher than the server-side interface version information provided in the client used by the service user, the verification is deemed successful. If the obtained server-side interface version information is lower than the server-side interface version information provided in the client used by the service user, the verification is determined to have failed.

5. The method according to any one of claims 2-4, characterized in that, The device manufacturer information indicates that the electronic device belongs to the target manufacturer; The step of determining the application identifier required for each query of the target server based on the service priority query order matching the device manufacturer information includes: Based on the service priority query order matching the device manufacturer information, the application identifiers required for each query of the target server are determined to be: a first application identifier and a second application identifier, wherein the first application identifier is the identifier of the APK where the first candidate server is located, and the second application identifier is the identifier of the APK where the second candidate server is located.

6. The method according to any one of claims 2-4, characterized in that, The device manufacturer information indicates that the electronic device does not belong to the target manufacturer; The step of determining the application identifier required for each query of the target server based on the service priority query order matching the device manufacturer information includes: Based on the service priority query order that matches the device manufacturer information, the application identifiers required for each query of the target server are determined to be the third application identifier, the fourth application identifier, and the second application identifier, respectively. The third application identifier is the identifier of the APK where the third candidate server is located, and the fourth application identifier is the identifier of the APK where the fourth candidate server is located.

7. The method as described in claim 6, characterized in that, The fourth application identifier is determined from the system configuration file, or the fourth application identifier is determined from the system attribute information.

8. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-7.

Images