Method for precise revocation of access control, related device and system

Abstract

The application provides an access control method for precisely revoking permissions, related devices and systems. In the method, a subject device can send an access request to an object device and permission information required by the access request granted by a user. The object device can create a first agent and grant the permissions required by the access request to the first agent. Then, the object device can respond to the access request through the first agent and revoke the permissions obtained by the object device by revoking the permissions granted to the first agent or terminating the first agent. The scheme can ensure that the object device obtains accurate permissions and can accurately and flexibly revoke the permissions as needed to protect the data security of the object device in the resource calling process.

Description

[0001] This application claims priority to Chinese Patent Application No. 202110327079.9, filed on March 26, 2021, entitled “Access Control Method, Related Apparatus and System for Precise Revocation of Rights”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the fields of computer and communication technology, and in particular to access control methods, related devices and systems for accurately revoking permissions. Background Technology

[0003] In a standalone scenario involving a single device, applications (apps) within that device can interact and access various resources. With the development of smart terminals, the types and number of devices in users' lives are increasing, and distributed scenarios where these devices are interconnected are gradually becoming a reality. In these distributed scenarios, sharing resources between devices, such as computing power, storage resources, and network resources, will become a future trend.

[0004] To protect user privacy, relevant technologies require that the electronic device being accessed must obtain permission to access sensitive information, and access to that sensitive information can only be granted after the permission check is passed.

[0005] During the invocation process, ensuring that the invoked electronic device obtains accurate permissions and being able to revoke those permissions as needed, thereby protecting data security and user privacy, is a problem that urgently needs to be solved. Summary of the Invention

[0006] This application provides an access control method, related apparatus, and system for accurately revoking permissions, which can ensure that the object device obtains accurate permissions and can accurately revoke those permissions as needed, thereby protecting the data security of the object device.

[0007] In a first aspect, embodiments of this application provide an access control method for accurately revoking permissions. This method is applied to a communication system including a first device and a second device. The first device has a callee installed, and the second device has a first caller installed. The callee and the first caller are application programs (APP) or functional components. An APP is a program entity that implements multiple functions, and a functional component is a program entity that implements a single function.

[0008] The method in the first aspect includes: a second device sending a first access request and first permission information to a first device, the first access request being used by a first caller to invoke a callee to access a first resource in the first device, the first permission information indicating a first permission, the first permission including the permission to invoke the callee, and / or the permission to access the first resource; the first device responding to the first access request granting the first permission to a first agent, and granting the callee the permission to access the first agent, the first agent being a service, process, or thread; the first device running the callee, accessing the first agent, and accessing the first resource through the first permission possessed by the first agent; the first device terminating the first agent, or the first device revoking the first permission possessed by the first agent.

[0009] In the first aspect of the method, the first device can be referred to as the object device, and the second device can be referred to as the subject device.

[0010] By implementing the method provided in the first aspect, the object device accesses the first resource through a first proxy, avoiding directly granting the permissions required for the access request to the callee. Even if the callee re-grants the permissions it has acquired to other callees, executing the above method will invalidate the re-granted permissions, thereby achieving the goal of accurately revoking permissions. Furthermore, through the first proxy, the object device does not need to store a large amount of permission delegation information, saving the object device's storage resources.

[0011] Furthermore, in the method provided in the first aspect, the primary device requests the necessary permissions from the user for access. Regardless of whether the object device or the callee has the authorization conditions, as long as the primary device or the caller has the authorization conditions, the object device can obtain the necessary permissions for the access request. This ensures that the access request initiated by the caller can be successfully responded to, realizing resource calls between devices and meeting the user's actual needs.

[0012] In conjunction with the first aspect, in some implementations, the first device may revoke the permissions required by the access request transmitted by the second device in any of the following circumstances:

[0013] 1. If the first permission information also indicates the validity period of the first permission, if the validity period is valid only once, the first device terminates the first proxy or revokes the first permission possessed by the first proxy after ending access to the first resource; if the validity period is valid within the first time or within the first area, the first device terminates the first proxy or revokes the first permission possessed by the first proxy after receiving the first permission information for the first time, or when located outside the first area.

[0014] 2. After the first device finishes accessing the first resource, or after a second time period following the end of access to the first resource, the first device terminates the first agent or revokes the first agent's first permissions.

[0015] The second method allows the object device to revoke permissions after successfully responding to an access request, without needing to transmit expiration information. This avoids situations where the permission expires before the resource call is completed, thus achieving the goal of accurately revoking permissions according to actual user needs.

[0016] In conjunction with the first aspect, in some implementations, the first device may grant access to the first instance of the callee to the first agent and run the first instance to access the first agent.

[0017] In the above embodiments, the communication system further includes a third device, which has a second caller installed. The second caller is an APP or a functional component. The third device can send a second access request and second permission information to the first device. The second access request is used by the second caller to call the callee to access the first resource. The second permission information indicates the second permission, which includes the permission to call the callee and / or the permission to access the first resource. In response to the second access request, the first device grants the second permission to a second proxy and grants the permission to access the second proxy to a second instance of the callee. The second proxy is a service, process, or thread. The first device runs the second instance, accesses the second proxy, and accesses the first resource through the second permission possessed by the second proxy. The first instance and the second instance are processes or threads running in random access memory (RAM). The second instance is different from the first instance and the second instance is isolated from the first instance.

[0018] Through the above implementation method, the object device provides services to multiple callers through multiple instances. The permissions obtained by the subject device can be granted to the revocation proxy corresponding to the instance of the callee created for that caller. This ensures that a caller's permissions are only granted to the revocation proxy corresponding to that instance, avoiding the problems of permission misuse and expansion, thereby ensuring data security in the object device and preventing data abuse and leakage.

[0019] In conjunction with the first aspect, in some implementations, the first device may also create a first instance in response to a first access request before granting access rights to the first agent to the first instance of the callee.

[0020] In conjunction with the first aspect, in some implementations, the first agent includes: a first routing agent and a first revocation agent; the first routing agent and the first revocation agent are services, processes, or threads. The first device can grant first permissions to the first revocation agent and grant access to the first routing agent to the callee. Furthermore, the first device can run the callee, access the first revocation agent through the first routing agent, and access the first resource using the first permissions granted by the first revocation agent. Additionally, the first device can terminate the first routing agent and / or the first revocation agent, or revoke the first permissions granted to the first revocation agent.

[0021] In the previous embodiment, if the first device also includes a second agent, which comprises a first routing agent and a first revocation agent, then the first routing agent and the second routing agent can be combined into a single agent. This can reduce resource consumption in the first device.

[0022] In conjunction with the first aspect, in some implementations, the first device may create a first agent in response to the first access request before granting the first permission to the first agent.

[0023] In conjunction with the first aspect, in some implementations, the first permission specifically includes: the permission of the second device to invoke the callee, and / or the permission of the second device to access the first resource; and / or the permission of the first caller to invoke the callee, and / or the permission of the first caller to access the first resource.

[0024] In the above implementation, if the permissions required by the access request include information about the subject device and / or the caller, the user can obtain more detailed information about the permissions required by the access request received by the current object device, and thus decide whether to grant the permission. This ensures that the user fully understands the permissions required by the access request before performing the authorization operation, avoiding user errors or misauthorization, and ensuring data security on the object device.

[0025] In conjunction with the first aspect, in some implementations, the second device can use capability-based access control technology to directly send the permission information required for the first access request to the first device simultaneously. For example, the permission information required for the first access request granted by the user can be carried in the first access request. This avoids the time overhead of permission synchronization in centralized permission management mechanisms and improves the efficiency of resource access.

[0026] In conjunction with the first aspect, in some embodiments, before the second device sends the first permission information to the first device, it may output a prompt message to indicate the first permission; the second device may also respond to a received user operation by sending the first permission information to the first device. In this way, the user can grant the first permission by inputting a user operation on the second device.

[0027] In conjunction with the previous embodiment, the operation received by the second device includes one or more of the following: user operation applied to the display screen, preset face image, preset fingerprint, preset voice command, or user operation applied to the button.

[0028] Secondly, this application provides an access control method for accurately revoking permissions. This method is applied to an electronic device, which has a callee installed in it. The callee is an application program (APP) or a functional component. An APP is a program entity that implements multiple functions, and a functional component is a program entity that implements a single function.

[0029] The second aspect of the method includes: an electronic device receiving a first access request and first permission information sent by a second device; the first access request is used by a first caller in the second device to call a callee to access a first resource in the electronic device; the first permission information indicates a first permission, which includes the permission to call the callee and / or the permission to access the first resource; the first caller is an APP or a functional component; in response to the first access request, the electronic device grants the first permission to a first agent and grants the callee the permission to access the first agent; the first agent is a service, process, or thread; the electronic device runs the callee, accesses the first agent, and accesses the first resource through the first permission possessed by the first agent; the electronic device terminates the first agent, or the electronic device revokes the first permission possessed by the first agent.

[0030] By implementing the method provided in the second aspect, the first device accesses the first resource through a first proxy, avoiding directly granting the permissions required for the access request to the callee. Even if the callee re-grants the permissions it has acquired to other callees, executing the above method will invalidate the re-granted permissions, thereby achieving the goal of accurately revoking permissions. Furthermore, through the first proxy, the first device does not need to store a large amount of permission delegation information, saving the first device's storage resources.

[0031] Furthermore, in the method provided in the second aspect, the primary device requests the necessary permissions from the user for access. Regardless of whether the object device or the callee has the authorization conditions, as long as the primary device or the caller has the authorization conditions, the object device can obtain the necessary permissions for the access request. This ensures that the access request initiated by the caller can be successfully responded to, realizing resource calls between devices and meeting the user's actual needs.

[0032] In the method provided in the second aspect, the various operations performed by the electronic device can be referred to the relevant description of the first device side in the method provided in the first aspect, and will not be repeated here.

[0033] Thirdly, this application provides an access control method for accurately revoking permissions. This method is applied to an electronic device, which has a first caller and a callee installed in it. The first caller and the callee are application programs (APP) or functional components. An APP is a program entity that implements multiple functions, and a functional component is a program entity that implements a single function.

[0034] The third aspect of the method includes: an electronic device generating a first access request and acquiring a first permission, the first access request being used by a first caller to invoke a callee to access a first resource in the electronic device, the first permission including the permission to invoke the callee and / or the permission to access the first resource; the electronic device responding to the first access request granting the first permission to a first agent and granting the callee the permission to access the first agent; the electronic device running the callee, accessing the first agent, and accessing the first resource through the first permission possessed by the first agent; the electronic device terminating the first agent, or the electronic device revoking the first permission possessed by the first agent.

[0035] By implementing the method provided by the third party, electronic devices can have their permissions revoked precisely and flexibly through the first agent.

[0036] In the first aspect, the second aspect, or any of the above embodiments, the operations performed by the first device, the second device, or the third device are all performed by the same electronic device in the method provided in the third aspect. Furthermore, the interaction between the second device or the third device and the third device can be omitted. For details, please refer to the relevant description above, which will not be repeated here.

[0037] Fourthly, embodiments of this application provide an electronic device, including: a memory and one or more processors; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the electronic device to perform the method as described in the second aspect or any embodiment of the second aspect.

[0038] Fifthly, embodiments of this application provide an electronic device, including: a memory and one or more processors; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the electronic device to perform the method as described in the third aspect or any of the embodiments of the third aspect.

[0039] In a sixth aspect, embodiments of this application provide a communication system, including a first device and a second device, wherein the first device is used to perform the method as described in the second aspect or any embodiment of the second aspect.

[0040] In a seventh aspect, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in the second aspect or any embodiment of the second aspect.

[0041] Eighthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method of the second aspect or any of the embodiments of the second aspect.

[0042] Ninthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in the third aspect or any of the embodiments of the third aspect.

[0043] In a tenth aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method of the third aspect or any of the embodiments of the third aspect.

[0044] By implementing the technical solution provided in this application, the principal device can send an access request to the object device for invoking the callee, and transmit the permission information required for the access request granted by the user to the object device. The object device can create a first proxy and grant the permissions required for the access request to the first proxy. Subsequently, the object device can respond to the access request through the first proxy. Furthermore, the object device can revoke the permissions acquired by the object device by revoking the permissions granted to the first proxy or terminating the first proxy. This solution ensures that the object device obtains accurate permissions and can precisely and flexibly revoke those permissions as needed, protecting the data security within the object device. Attached Figure Description

[0045] Figure 1A and Figure 1B These are schematic diagrams illustrating one type of permission check method;

[0046] Figure 2A This is a schematic diagram of the structure of the communication system 10 provided in an embodiment of this application;

[0047] Figure 2B This application provides a distributed scenario for an embodiment of the present application;

[0048] Figure 3A A hardware structure diagram of the electronic device provided in the embodiments of this application;

[0049] Figure 3B A software structure diagram of the electronic device provided in the embodiments of this application;

[0050] Figure 4 A flowchart illustrating the access control method for precisely revoking permissions provided in this application embodiment;

[0051] Figures 5A-5C A set of user interfaces implemented on the main device 200 provided in the embodiments of this application;

[0052] Figures 5D-5F A set of user interfaces implemented on the main device 300 provided in the embodiments of this application;

[0053] Figure 6A A schematic diagram illustrating the creation of an agent and the granting of permissions, provided as an embodiment of this application;

[0054] Figure 6B This application provides another schematic diagram illustrating the creation of an agent and the granting of permissions;

[0055] Figure 7A The software structure diagram of the main device provided in the embodiments of this application;

[0056] Figure 7B The software structure diagram of the object device provided in the embodiments of this application;

[0057] Figure 8 The process of implementing an access control method based on binder for a single electronic device provided in the embodiments of this application. Detailed Implementation

[0058] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text 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, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0059] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0060] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0061] In a distributed system containing multiple electronic devices, if the accessed electronic device lacks authorization, or if the invoked application lacks authorization, the electronic device cannot obtain the user-granted access permissions to resources. Therefore, resource calls within a single device or between devices cannot be implemented, failing to meet the user's actual needs. Having authorization means that the electronic device supports one or more authorization methods for user authorization. Authorization methods may include, but are not limited to: pop-up authorization, fingerprint verification authorization, facial verification authorization, voice command authorization, button authorization, etc., without further restrictions. Lack of authorization means that the application cannot use the various authorization methods provided by the electronic device. For example, if the application does not provide a user interface, it does not support pop-up authorization.

[0062] refer to Figure 1A In standalone devices or distributed systems containing multiple electronic devices, a centralized access control mechanism can be adopted. This means that an access control module (i.e., an access control service) manages the access policies and authorization status for resource calls in a unified manner. Specifically, when one application (e.g., APP1) calls another application (e.g., APP2), APP2 verifies whether APP1 has the necessary permissions to access the corresponding resource through the access control module, incurring additional time overhead. Furthermore, when making resource calls across devices, the device containing APP1 needs to separately send the access policy and user authorization status to the device containing APP2, resulting in significant time overhead.

[0063] refer to Figure 1BThe resource invocation based on the cloud service platform employs capability-based access control technology. Specifically, when a service caller requests access to a service provided by the cloud service platform, it directly passes the necessary permissions to the service entity, enabling the service entity to access the corresponding resource and return the access result. This allows the service entity to directly perform permission checks, eliminating the need for additional permission verification through the access control module and reducing time overhead. However, once permissions are passed to the service entity, there is a problem with revoking them. On one hand, when passing permissions to the service entity, the caller also passes expiration information, and the permission automatically expires after the service entity's expiration date. This method may result in the permission expiring before the resource invocation is completed, thus failing to accurately revoke permissions according to actual needs. On the other hand, the cloud service platform needs to record a large amount of permission delegation information, wasting storage resources. Furthermore, service entities may re-transfer the acquired permissions, meaning that when the cloud service platform revokes permissions based on the delegation information, it cannot accurately revoke the permissions held by all service entities that have acquired them.

[0064] To address the aforementioned issues, the following embodiments of this application provide an access control method for accurately revoking permissions. This access control method can be applied to a single device or to a distributed system containing multiple electronic devices.

[0065] When applied to a distributed system, this method involves the principal device sending an access request to the object device to invoke the callee, and passing the necessary permissions granted by the user to the object device. The object device can create a proxy module and grant access to the proxy module to the callee, as well as the permissions required for the access request, to the proxy module. The object device can then create and run an instance of the callee, responding to the access request initiated by the principal device through the proxy module. Subsequently, when it is necessary to revoke the permissions required for the access request, the object device can revoke the permissions granted to the proxy module or terminate the proxy module.

[0066] Using the above method, the primary device and the caller request the necessary permissions from the user for access. Regardless of whether the object device or the callee has the authorization conditions, as long as the primary device or the caller has the authorization conditions, the object device can obtain the necessary permissions for access. This ensures that the access request initiated by the caller can be successfully responded to, realizing resource access between devices and meeting the user's actual needs.

[0067] Furthermore, the object device responds to access requests by creating a proxy module. In this process, the instance of the callee and the proxy module each perform permission checks directly, without the need for additional permission verification through the access control module, thus reducing time overhead.

[0068] Furthermore, by creating a proxy module, the object device can accurately and flexibly revoke the permissions required for the access request. The object device can revoke the permissions required for the access request after obtaining the access result, without needing to transmit expiration information, thus avoiding the situation where the permission expires before the resource call is completed. Through the proxy module, the object device does not need to store a large amount of permission delegation information, and even if the object device re-transfers the acquired permissions, the method provided in this application embodiment can still revoke the permissions held by all instances that acquired them, achieving precise revocation.

[0069] In some embodiments, when the subject device sends an access request, it can use capability-based access control technology to directly send the permission information required for the access request to the object device, thus avoiding the time overhead caused by permission synchronization in a centralized permission management mechanism.

[0070] In the following embodiments of this application, the proxy module can be an application, a service, an instance, a process, or a thread. A process is an execution activity of an application on a computer. A thread is a single sequential control flow in the execution of an application. A process may include multiple threads.

[0071] In some embodiments, the proxy module may specifically include a routing proxy and a revocation proxy, which is not limited in this application embodiment. Specifically, the object device may grant the callee permission to access the routing proxy and grant the revocation proxy the permissions required for the access request. The object device may create and run an instance of the callee, find the corresponding revocation proxy through the routing proxy, and respond to the access request initiated by the subject device through the revocation proxy. Subsequently, when it is necessary to revoke the permissions required for the access request, the object device may revoke the permissions granted to the revocation proxy, or terminate the revocation proxy and / or the routing proxy.

[0072] When an object device receives multiple access requests, it can create different routing proxies and revocation proxies, with a pair of routing proxies and revocation proxies used to respond to each access request. In other implementations, when an object device receives multiple access requests, it can create one routing proxy and multiple revocation proxies, which cooperate to respond to each access request.

[0073] In some embodiments, when an object device receives access requests from multiple subject devices for invoking the same callee, the object device can create multiple instances of the callee. Each instance of the callee is used to respond to an access request initiated by a caller. The object device can grant the permissions obtained by the caller in the subject devices to the proxy module corresponding to the instance of the callee created for that caller. In this way, by providing services to multiple callers through multiple instances, the object device ensures that the permissions of a caller are only granted to the proxy module corresponding to that instance. This avoids the problems of permission misuse and privilege escalation, thereby ensuring data security in the object device and preventing data abuse and leakage.

[0074] When the access control method provided in this application is applied to a standalone device, the electronic device, during the operation of the caller, generates multiple access requests for calling the callee and can obtain the permissions required for the access request granted by the user. Then, the electronic device can create a proxy module and grant the callee access to the proxy module, as well as grant the proxy module the permissions required for the access request. The electronic device can create and run an instance of the callee, responding to the access request through the proxy module. Subsequently, when it is necessary to revoke the permissions required for the access request, the electronic device can revoke the permissions granted to the proxy module and terminate the proxy module.

[0075] In a standalone device, the caller within the electronic device requests the necessary permissions from the user. Regardless of whether the callee possesses the authorization, as long as the caller does, the electronic device can obtain the required permissions. This ensures that the caller's access request is successfully responded to, enabling resource access within the standalone device and meeting the user's actual needs.

[0076] Furthermore, electronic devices can precisely and flexibly revoke the permissions required for an access request by creating a proxy module. In addition, the proxy module can directly perform permission verification without the need for an additional access control module, thus avoiding the time overhead associated with permission verification. For details, please refer to the relevant descriptions when implementing this access control method in a distributed system.

[0077] In some embodiments, when an electronic device receives multiple access requests for invoking the same callee, it can create multiple instances of that callee. Each instance of the callee is used to respond to an access request initiated by a caller. The electronic device can grant the permissions obtained by the caller to the proxy module corresponding to the instance of the callee created for that caller. By providing services to multiple callers through multiple instances, it ensures that a caller's permissions are only granted to the proxy module corresponding to that instance, avoiding issues of permission misuse and escalation, thereby ensuring data security within the electronic device and preventing data misuse and leakage.

[0078] In the following embodiments of this application, an instance is a running application or functional component. An instance can refer to a process or a thread.

[0079] Instances are isolated from each other. Electronic devices allocate physical addresses in random access memory (RAM) to different instances on a process-by-process basis. When an electronic device needs to run an instance, it locates the corresponding space in RAM allocated to that instance based on its virtual address and runs the instance within that space. This virtual address maps to the physical address allocated to the instance by the electronic device, and this mapping is stored in the electronic device's controller. In other words, instances use virtual addresses to find the actual storage location of memory data. Under this mechanism, different instances can only access the physical address corresponding to their own virtual address; they cannot access each other's physical space in RAM, thus ensuring isolation between instances.

[0080] The definitions of subject device, object device, caller, and callee can be found in the relevant descriptions in the embodiments below.

[0081] The communication system provided in the embodiments of this application will be introduced below.

[0082] like Figure 2A As shown, this application embodiment provides a communication system 10. The communication system 10 includes multiple electronic devices. The communication system 10 can also be referred to as a distributed system 10.

[0083] The distributed system 10 includes multiple electronic devices, all of which are smart terminal devices and can be of various types. This application embodiment does not limit the specific types of these multiple electronic devices. For example, these multiple electronic devices may include mobile phones, but may also include tablets, desktop computers, laptops, handheld computers, smart screens, wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, in-vehicle systems, smart headphones, game consoles, and may also include Internet of Things (IoT) devices or smart home devices such as smart water heaters, smart lights, smart air conditioners, etc. However, the multiple devices in the distributed system 10 may also include non-portable terminal devices such as laptops with touch-sensitive surfaces or touch panels, and desktop computers with touch-sensitive surfaces or touch panels.

[0084] When multiple electronic devices in the distributed system 10 are devices deployed in a home, the distributed system 10 can also be referred to as a home distributed system.

[0085] In distributed system 10, multiple electronic devices can connect by logging into the same account. For example, multiple electronic devices can log into the same Huawei account and remotely connect and communicate through a server.

[0086] In distributed system 10, multiple electronic devices can log in to different accounts, but they are connected through a binding method. After an electronic device logs in to an account, it can bind other electronic devices that are logged in with different accounts or are not logged in, in the device management application. Afterwards, these electronic devices can communicate with each other through the device management application.

[0087] Multiple electronic devices in the distributed system 10 can also establish connections through scanning QR codes, tapping with near field communication (NFC), searching for Bluetooth devices, etc., without any restrictions.

[0088] In general, the communication connections established between multiple electronic devices in the distributed system 10 may include, but are not limited to: wired connections, wireless connections such as Bluetooth (BT) connections, wireless local area networks (WLANs) such as wireless fidelity point-to-point (Wi-Fi P2P) connections, near field communication (NFC) connections, infrared (IR) connections, and remote connections (such as connections established through a server), etc.

[0089] Furthermore, multiple electronic devices in a distributed system can also be connected and communicate using any of the above methods, and this application embodiment does not impose any restrictions on this.

[0090] Multiple electronic devices in distributed system 10 can be configured with different software operating systems (OS), including but not limited to... And so on. Among them, It refers to Huawei's HarmonyOS operating system.

[0091] These multiple electronic devices can also all be configured with the same software operating system; for example, they can all be configured with... The software systems of multiple electronic devices are At that time, distributed system 10 can be regarded as a super terminal.

[0092] In this embodiment, each device in the distributed system 10 can install traditional applications (APPs), such as camera applications, gallery applications, settings applications, etc. In subsequent embodiments, traditional APPs can be simply referred to as APPs.

[0093] Furthermore, the distributed system 10 provided in this application embodiment can install distributed applications. These distributed applications can be system applications or third-party applications; no limitation is made here. System applications refer to applications provided or developed by the manufacturer of the electronic equipment, while third-party applications refer to applications provided or developed by a non-electronic equipment manufacturer. The manufacturer of the electronic equipment can include the manufacturer, supplier, provider, or operator of the electronic equipment. A manufacturer can refer to a production company that manufactures electronic equipment using self-made or purchased parts and raw materials. A supplier can refer to a manufacturer that provides the complete electronic equipment, raw materials, or parts. An operator can refer to a manufacturer responsible for distributing the electronic equipment.

[0094] Unlike apps that include multiple capabilities, distributed applications can be deployed on a single capability basis. A distributed application consists of one or more functional components.

[0095] A functional component is the smallest independently operable unit in an electronic device; it's a concept that abstracts and encapsulates a single capability. While an app combines multiple functions, a functional component treats each function as a separate, service-oriented capability, existing independently. In other words, a functional component is a program entity that implements a single function.

[0096] Each functional component can be downloaded, installed, and run independently. Multiple functional components that make up the same distributed application can be deployed on the same electronic device in the distributed system 10, or they can be deployed on different electronic devices.

[0097] "Functional component" is simply a term used in this embodiment, and its meaning has been described in this embodiment. Its name does not constitute any limitation on this embodiment. Furthermore, in other embodiments of this application, functional component may also be referred to as system component, system service, business function, or other terms. Subsequent embodiments of this application will uniformly use the term "functional component" for description.

[0098] by For example, The functional components can include the following two categories:

[0099] (1) Feature ability, FA.

[0100] A Functional Interface (FA) is a set of one or more UI components that provide the ability to interact with the user. For example, the navigation interface in a map application or the video call interface in an instant messaging application can be implemented as an FA.

[0101] In some embodiments, FA is developed based on the MVVM (model-view-view-model) pattern, separating the view UI from the business logic, and deploying the business logic code and view UI code separately. For example, an electronic device can integrate the business logic code with other apps for installation, while the view UI code can be installed on other electronic devices. The device where the view UI code resides can communicate with the device where the business logic code resides to obtain the data needed to display the UI.

[0102] FA supports page template capabilities, such as Empty Ability, Login Ability, and Setting Ability. FA uses a scripting language (JavaScript, JS) to provide a declarative development model, employing HTML-like and cascading style sheet (CSS) declarative programming languages ​​for page layout and styling, and also supports ECMAScript-compliant JS for providing page business logic.

[0103] FA features include installation-free operation, standalone operation, cross-device UI migration, and cross-device binary migration capabilities. FA also boasts multi-platform deployment and distributed execution.

[0104] FA can call AA or APP to achieve more and more complex functions.

[0105] (2) Particle ability, PA.

[0106] PA (Application Component) is a UI-less functional component that provides support for FA (Application Component). For example, PA can provide computing power as a background service or provide data access capabilities as a data warehouse. Features such as beautification, location services, and audio / video encoding / decoding can be encapsulated as PAs.

[0107] PA also features multi-terminal deployment and distributed execution. PA only depends on system services and has no dependencies on other PAs.

[0108] PA essentially encapsulates remote virtualization, remote invocation, PA management, cross-platform compatibility, and security, providing developers with cross-device service enablement and invocation capabilities. This allows other devices to access the computing power of PA and collaborate with other devices to complete computational tasks. PA supports Service Ability and Data Ability. Service Ability provides the ability to run background tasks, while Data Ability provides a unified data access abstraction to the outside world.

[0109] PA can call FA or APP to achieve more and more complex functions.

[0110] It is understood that "FA" and "PA" are just terms used in this embodiment, and may be referred to as other terms in other embodiments of this application. For example, "PA" and "FA" may also be referred to as atomic capability (AA), atomic application, meta-capability, atomic service, feature capability, and other terms.

[0111] The multiple functional components that make up a distributed application can be developed or provided by the same developer, or they can be developed or provided separately by multiple developers; there are no restrictions here. Collaborating on functional components by different developers can improve the development efficiency of distributed applications.

[0112] In this embodiment, the functional component provides a standardized interface for invocation. The app can invoke the functional component. In some cases, the functional component can also invoke other functional components or the app. Furthermore, the invoked functional component can continue to invoke other functional components or the app; this multi-level invocation method can be called chained invocation.

[0113] After establishing communication connections among the devices in the distributed system 10, each device will synchronize the functional component information and APP information of other devices in the distributed system. Specifically, each device can synchronize the names of its installed functional components and APPs with other devices, so that they can subsequently call the FA, PA, and other functional components of other devices in the distributed system 10. In some other embodiments, each device can also synchronize its device identifier, device type, etc., with other devices in the distributed system.

[0114] refer to Figure 2B , Figure 2B An example is shown of a possible distributed remote teaching business scenario.

[0115] like Figure 2B As shown, the distributed system includes electronic devices such as smartphones, tablets, and smart screens. Each device in the distributed system is interconnected. Smartphones, tablets, and smart screens can be configured with different software operating systems (OS). For example, smartphones and tablets can be configured with... The system and smart screen can be configured system.

[0116] A smartphone has an "Online Classroom" application installed. This "Online Classroom" is an application installed on an electronic device that provides teachers and students with the necessary functions for remote classes; the name of this application is not limited. The "Online Classroom" may include the following functional components: a blackboard component, a whiteboard component, an audio / video encoding / decoding component, and a network connection component. The blackboard and whiteboard components belong to the FA (Software Aspect), while the audio / video encoding / decoding component and network connection component belong to the PA (Power Aspect). The blackboard component provides the function of remotely explaining courses. The whiteboard component provides the function of remotely answering questions. The audio / video encoding / decoding component provides video and audio encoding / decoding functions.

[0117] On the teacher's side, when using "Online Classroom" on a smartphone, the teacher can migrate or switch the blackboard function component to the smart screen, thereby explaining the course on the smart screen.

[0118] On the student side, when students use the "online classroom" on their smartphones, they can migrate or switch the whiteboard functionality to a tablet, allowing them to answer questions on the tablet.

[0119] Migrating or switching a functional component from device A to device B can include the following two types: 1. UI migration. When the view UI and business logic of the functional component are separated, if device A can run the business logic code, it can trigger device B to run the view UI code. From the user's perspective, it appears as if the functional component has been migrated from device A to device B. 2. Overall migration. Overall migration refers to device B downloading and installing the functional component from device A or from the network, then running the functional component and providing the corresponding functionality.

[0120] In this remote teaching scenario, the "online classroom" is the caller, and the whiteboard function component on the tablet and the blackboard function component on the smart screen are the callees.

[0121] Figure 2B It also demonstrates another possible scenario for distributed video call services.

[0122] like Figure 2B As shown, smartphones can also install other distributed applications, such as instant messaging applications. Instant messaging applications can provide video calls, voice calls, and other communication functions. Instant messaging applications may include the following functional components: video calling functional components, audio and video codec functional components, and network connectivity functional components.

[0123] When users use instant messaging apps on their smartphones, they can migrate or switch the video call function of the app to the smart screen, thereby utilizing the smart screen's camera and display for video calls.

[0124] The blackboard function component in the aforementioned "online classroom" and the video call function component in the instant messaging application can be the same function component. In other words, this function component in the smart screen can be called by both the "online classroom" and the instant messaging application installed on the smartphone.

[0125] In this video call service scenario, the instant messaging application is the caller, and the video call function component in the smart screen (i.e., the video call function component) is the callee.

[0126] It should be noted that, as Figure 2B The business scenarios illustrated are for illustrative purposes only, serving to help describe the technical solutions of the embodiments of this application. In actual business scenarios, Figure 2BThe distributed system shown may include more terminal devices, each of which may deploy more or fewer functional components, and each distributed application may include more or fewer functional components.

[0127] pass Figure 2A The distributed system 10 shown, and, Figure 2B The distributed scenario shown can integrate the software and hardware capabilities of different devices to achieve a smart, full-scenario experience.

[0128] In some embodiments, after the devices in the distributed system 10 establish a communication connection, each device will synchronize the functional component information and APP information of other devices in the distributed system. Specifically, each device can synchronize the names of its installed functional components and APPs with other devices, so that the APPs, functional components, etc. of other devices can be called in the distributed system 10 later.

[0129] In subsequent embodiments of this application: the party initiating the call to a functional component or APP can be referred to as the caller. The caller can be, for example, an APP, a FA, or a PA. The initial initiator of the entire call chain can be referred to as the first caller. The first caller can be, for example, an APP or a FA. For example, if the call chain is: APP1 calls PA1, PA1 calls PA2, PA2 calls FA1, then APP1 is the first caller. As another example, if the call chain is: FA1 calls PA1, PA1 calls PA2, then FA1 is the first caller.

[0130] In the entire call chain, the party called in the middle and the party called last can both be called the callee. The callee can be, for example, an APP, a FA, or a PA.

[0131] In some embodiments of this application, the caller may also be referred to as the subject application, and the callee may also be referred to as the object application.

[0132] In a call chain, the caller and the callee can be deployed on the same electronic device or on different electronic devices.

[0133] The device where the caller is located is called the subject device, and the device where the callee is located is called the object device.

[0134] The applications referred to in the following embodiments of this application may include APPs or functional components.

[0135] In the distributed system 10 provided in the embodiments of this application:

[0136] After the main device generates an access request to invoke the callee in the object device, it can request the user to grant the necessary permissions for the access request. Then, it can send the access request and the permission information granted by the user to the object device.

[0137] After receiving an access request from the principal device, the object device can create a proxy module, grant the necessary permissions to the proxy module, and then grant the callee the permissions to access the proxy module. The object device can create and run an instance of the callee, using the proxy module to respond to access requests initiated by the principal device. Subsequently, when it is necessary to revoke the permissions required for the access request, the object device can revoke the permissions granted to the proxy module or terminate the proxy module.

[0138] In some embodiments, when an object device receives access requests from multiple subject devices for invoking the same callee, the object device may create multiple instances of the callee, with one instance of the callee used to respond to an access request initiated by a caller.

[0139] In some embodiments, when the subject device and the object device are the same electronic device, the electronic device, during the execution of the caller, generates multiple access requests for invoking the callee and can obtain the permissions required for the access requests granted by the user. The electronic device can then create a proxy module and grant the callee permission to access the proxy module, as well as grant the proxy module the permissions required for the access requests. The electronic device can create and run an instance of the callee, responding to access requests through the proxy module. Subsequently, when it is necessary to revoke the permissions required for the access requests, the electronic device can revoke the permissions granted to the proxy module and terminate the proxy module.

[0140] In some embodiments, when the subject device and the object device are the same electronic device, if the electronic device receives multiple access requests for invoking the same callee, the electronic device may create multiple instances of the callee, with one instance of the callee used to respond to an access request initiated by a caller.

[0141] For details on the specific implementation of the operations performed by each electronic device in the distributed system 10, please refer to the relevant descriptions in the subsequent method embodiments, which will not be repeated here.

[0142] refer to Figure 3A , Figure 3A This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device can be... Figure 2A Any electronic device in the distributed system 10 shown. This electronic device can be a subject device, an object device, or both.

[0143] like Figure 3A As shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. 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.

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

[0145] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0146] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0147] 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 the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

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

[0149] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

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

[0151] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0152] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, frequency modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0153] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the electronic device to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

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

[0155] 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 miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device may include one or N displays 194, where N is a positive integer greater than 1.

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

[0157] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization of image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0158] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the electronic device may include one or N cameras 193, where N is a positive integer greater than 1.

[0159] Digital signal processors (DSPs) are used to process digital signals, including digital image signals and other digital signals. For example, when an electronic device is selecting a frequency, a DSP can perform Fourier transforms on the frequency energy.

[0160] Video codecs are used to compress or decompress digital video. Electronic devices can support one or more video codecs. This allows the electronic device to play or record video in various encoded formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0161] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0162] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0163] Random access memory can include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and double data rate synchronous dynamic random access memory (DDR SDRAM, such as fifth-generation DDR SDRAM, which is generally called DDR5 SDRAM). Non-volatile memory can include disk storage devices and flash memory.

[0164] The random access memory can be directly read and written by the processor 110. It can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data.

[0165] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.

[0166] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the electronic device. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0167] Electronic devices can implement audio functions such as music playback and recording through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors.

[0168] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0169] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. Electronic devices can listen to music or make hands-free calls through the speaker 170A.

[0170] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When an electronic device answers a phone call or voice message, the receiver 170B can be brought close to the ear to hear the voice.

[0171] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. Electronic devices can have at least one microphone 170C. In some embodiments, electronic devices can have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, electronic devices can have three, four, or more microphones 170C, enabling sound signal collection, noise reduction, sound source identification, and directional recording, among other functions.

[0172] The fingerprint sensor 180H is used to collect fingerprints. Electronic devices can utilize the characteristics of the collected fingerprints to achieve fingerprint unlocking, app access locks, fingerprint photography, fingerprint answering of calls, etc.

[0173] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. The electronic device can receive button input and generate key signal inputs related to user settings and function control of the electronic device.

[0174] Motor 191 can generate vibration alerts.

[0175] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0176] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194.

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

[0178] when Figure 3A When the electronic device shown is the main device:

[0179] The mobile communication module 150 or the wireless communication module 160 can be used to establish a communication connection with other electronic devices (e.g., object devices) in the distributed system 10. For details on how to establish the communication connection, please refer to [reference needed]. Figure 2A The relevant description in the document.

[0180] The mobile communication module 150 or the wireless communication module 160 can also be used to receive synchronized functional component information and APP information from other electronic devices after establishing a communication connection with them.

[0181] The display screen 194, fingerprint sensor 180H, camera 193, audio module 170, button 190, and other modules can be used to provide various authorization methods to request the user to grant the necessary permissions after the main device generates an access request for calling the callee in the object device. The processor 110 can respond to the user operation received by the above modules and obtain the permissions required for the access request granted by the user.

[0182] The mobile communication module 150 or the wireless communication module 160 can also be used to send access requests and user-granted permission information to the object device.

[0183] The display screen 194 can also be used to display the user interface provided in subsequent embodiments that is displayed on the main device.

[0184] The internal memory 121 can be used to store functional component information and APP information synchronized from other electronic devices in the distributed system 10.

[0185] The internal memory 121 can also be used to store the calling relationship between the caller in the subject device and the callee in the object device. This calling relationship includes: a calling relationship ID, information about the caller, and information about the callee. The specific content of this calling relationship can be found in the relevant description of subsequent embodiments.

[0186] when Figure 3A When the electronic device shown is an object device:

[0187] The mobile communication module 150 or the wireless communication module 160 can be used to establish a communication connection with other electronic devices (such as the main device) in the distributed system 10. For details on how to establish the communication connection, please refer to [reference needed]. Figure 2A Related descriptions.

[0188] The mobile communication module 150 or the wireless communication module 160 can also be used to synchronize functional component information and APP information with other electronic devices after establishing a communication connection with them.

[0189] The mobile communication module 150 or the wireless communication module 160 can also be used to receive access requests sent by one or more master devices for calling the same callee, and to receive the permission information required for the user-granted access request sent by the master device.

[0190] The processor 110 can be used to respond to multiple access requests sent by multiple subject devices, and create multiple instances of the callee, with one instance of the callee used to respond to an access request initiated by a caller.

[0191] Processor 110 can be used to create proxy modules and grant access permissions to the callee to the proxy modules, as well as grant the proxy modules the permissions required for the access request. Processor 110 can create and run an instance of the callee, which responds to access requests initiated by the principal device through the proxy modules. Subsequently, when it is necessary to revoke the permissions required for the access request, processor 110 can revoke the permissions granted to the proxy modules and terminate the proxy modules.

[0192] In some embodiments, when an object device receives access requests from multiple subject devices for invoking the same callee, the processor 110 may create multiple instances of the callee, with each instance of the callee used to respond to an access request initiated by a caller. The processor 110 may grant permissions obtained by the caller in the subject devices to the instance of the callee created for that caller.

[0193] The display screen 194 can also be used to display a user interface displayed on an object device as provided in subsequent embodiments.

[0194] The internal memory 121 can be used to store permission information, timeliness information, etc., required for access requests sent by various main devices.

[0195] The internal memory 121 can also be used to store the calling relationship between the callee in the object device and the caller in the subject device. This calling relationship includes: a calling relationship ID, instance information of the callee, and information about each caller that calls that instance. The specific content of this calling relationship can be found in the relevant description in subsequent embodiments.

[0196] when Figure 3A When the electronic device shown serves as both a subject device and an object device, all operations performed by the modules in both the subject device and the object device are executed by this electronic device, and the communication steps between the subject device and the object device can be omitted. The operations performed by each module in this electronic device can be referred to the relevant descriptions above, and will not be repeated here.

[0197] refer to Figure 3B , Figure 3B This is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application. The electronic device can be... Figure 2A Any electronic device in the distributed system 10 shown. This electronic device can be a subject device, an object device, or both.

[0198] The software systems of electronic devices can adopt layered architectures, event-driven architectures, microkernel architectures, microservice architectures, or cloud architectures, etc. For example, the software systems of electronic devices include, but are not limited to, those mentioned above. Linux or other operating systems.

[0199] 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 and system libraries, and the kernel layer.

[0200] The application layer can include a series of application packages.

[0201] like Figure 3B As shown, the application package can include apps such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS applications. The application layer may also include functional components such as FA, PA, etc.

[0202] 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.

[0203] like Figure 3B As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0204] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0205] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0206] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0207] A phone manager is used to provide communication functions for electronic devices. For example, it manages call status (including connection and disconnection).

[0208] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0209] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0210] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0211] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0212] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0213] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0214] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0215] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0216] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0217] A 2D graphics engine is a graphics engine for 2D drawing.

[0218] 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.

[0219] based on Figure 2A Distributed system 10 shown, Figure 3A The hardware structure of the electronic device shown is as follows: Figure 3B The software structure of the electronic device shown is described below. The access control method for accurately revoking permissions provided in the embodiments of this application will be described in detail below.

[0220] refer to Figure 4 , Figure 4 This is a flowchart illustrating the access control method for precisely revoking permissions provided in an embodiment of this application. Figure 4 The method shown is illustrated using the example of a subject device calling resources in an object device.

[0221] like Figure 4 As shown, the method may include the following steps:

[0222] S101, The object equipment and the main equipment establish a connection, and the number of main equipment is one or more.

[0223] The number of object devices is one, and the object device can be any electronic device in the distributed system 10.

[0224] The number of master devices can be one or more. Master devices can be any electronic device in the distributed system 10.

[0225] This application does not limit the method by which the object device and the subject device establish a communication connection. For example, a communication connection can be established by logging into the same account, binding the device, scanning a QR code, etc. This application also does not limit the type of communication connection established between the subject device and the object device. For example, it may include wired connections, wireless connections such as Bluetooth connections, Wi-Fi P2P connections, NFC connections, IR connections, and remote connections, etc. See details for further information. Figure 2A The relevant description in the document.

[0226] In some embodiments, after the object device and the subject device establish a connection, the object device can send information about its installed, callable functional components and APP information, such as identifiers, to the subject device. The callable functional components or APPs are declared or defined by the developer during the development phase. Here, "callable" simply means that the functional components or APPs can be invoked by a caller, not that they are open or authorized to be invoked by a specific device.

[0227] In some embodiments, after a connection is established between the object device and the subject device, the object device can send capability information to the subject device that is open to it. This capability information indicates which apps, functional components, resources, etc., the object device makes available to the subject device for use. Here, the capability information open to the subject device means that the corresponding apps, functional components, and resources can be used by the subject device. The capabilities that the object device makes available to the subject device can be preset by the object device or set by the user. For example, an electronic device can make apps or functional components with low confidentiality or low sensitivity available to other devices. For instance, an electronic device can make camera apps and gallery apps available to other devices, but not banking apps. The capabilities that the object device makes available to different subject devices can be the same or different; there is no restriction on this.

[0228] S102, the main device generates an access request, which is used by the caller in the main device to call the callee in the object device to access the first resource.

[0229] In this embodiment, the caller is installed in the subject device, and the callee is installed in the object device. Both the caller and the callee can be an app or a functional component. The definitions of apps and functional components can be found in the preceding descriptions.

[0230] The access request generated by the subject device may include: the caller's identifier, the callee's identifier, and the identifier of the first resource. In some embodiments, the access request may further include: the subject device's identifier and the object device's identifier.

[0231] The identifier for the main device or the object device can be the device type, device model, device name, etc., and this application embodiment does not limit this. The device type here can be viewed from the perspective of device function, and may include, for example, mobile phones, tablets, smart headphones, IoT devices, or smart home devices, etc.

[0232] The caller's identifier and the callee's identifier can be the application identifier (APP ID).

[0233] In this embodiment, the first resource can be a software resource or a hardware resource. Hardware resources may include, for example, the device's camera, fingerprint sensor, audio device, display screen, motor, flash, etc. Software resources may include, for example, the device's memory resources, computing power (e.g., beautification algorithm capabilities, audio / video encoding / decoding capabilities), network capabilities, positioning functions, etc. The first resource may include one or more resources, without limitation.

[0234] In some cases, the identifier of the callee and the identifier of the first resource can be the same. For example, when the first resource is a camera, the identifier of the callee can also be the identifier of the camera, indicating that the callee is a camera application.

[0235] In this embodiment of the application, each access request corresponds to an initiating device (i.e., the principal device), a caller, a callee, and a first resource to be accessed. The callee and the first resource are the same for different access requests, but the principal device and the caller may be different for different access requests.

[0236] In some embodiments, the host device may generate an access request in response to a received user operation during the operation of the caller.

[0237] The following explanation uses the example of the main device 200 and the main device 300 each generating an access request for the object device 100. The main device 200 can be a tablet computer, the main device 300 can be a smart screen, and the object device 100 can be a smartphone.

[0238] Figure 5AThe user interface 51 provided by the "Gallery" in the main device 200 is illustrated. The "Gallery" is an image management application installed on the electronic device, also known as a "photo album," and this embodiment does not limit the name of the application. The "Gallery" allows users to perform various operations on images stored on the electronic device or a cloud server, such as browsing, editing, deleting, and selecting.

[0239] like Figure 5A As shown, the user interface 51 displays: a status bar 501, a back button 502, a page indicator 503, an image 504, and one or more device options 505.

[0240] The status bar 501 may include: one or more Wi-Fi signal strength indicators, battery status indicators, time indicators, etc.

[0241] The back button 502 is used to return to the previous page provided by "Gallery".

[0242] Page indicator 503 is used to indicate that the current page is provided by "Gallery". Page indicator 503 can be implemented as text such as the text "Gallery", an icon, or other forms.

[0243] Image 504 can be an image stored on the main device 200 or a cloud server. Image 504 can be taken by the main device 200, downloaded by the main device 200 from the network, or shared from other devices.

[0244] One or more device options 505 may correspond to devices in the distributed system 10 that can provide image processing capabilities to meet the image processing needs of the main device 200, such as smartphones. Device options 505 can be implemented as images, icons, text, etc., without limitation.

[0245] like Figure 5A As shown, the main device 200 can detect user operations on device option 505 and, in response to the user operations, generate an access request. This access request is used by the "Gallery" application in the main device 200 to call the image processing function component (FA) and image processing resources in the smartphone 1 (i.e., the object device 100) corresponding to device option 505.

[0246] Figure 5D An example is shown of the user interface 52 provided by the "Gallery" in the main device 300. For example... Figure 5D As shown, the user interface 52 displays: a status bar, a back button, a page indicator, an image 508, and one or more device options 509.

[0247] Status bar, back button, page indicator, image 508, one or more device options 509, please refer to Figure 5A The relevant description in the document.

[0248] like Figure 5D As shown, the main device 300 can detect user operations on device option 509, such as user operations where the user selects device option 509 via remote control, and in response to the user operation, generate an access request. This access request is used by the "Gallery" application in the main device 300 to call the image processing function component (FA) and image processing resources in the smartphone 1 (i.e., the object device 100) corresponding to device option 505.

[0249] In other embodiments, the primary device may also autonomously generate access requests for the secondary device under certain circumstances during the operation of the caller. For example, the primary device may generate by default an access request for the instant messaging application in the primary device to call the video call function components and camera resources in the smart screen (i.e., secondary device 100) each time a video call is made.

[0250] In some embodiments, after generating an access request, the principal device can also query whether the object device has granted the principal device permission to access the callee and / or the first resource in the access request. If so, subsequent steps are then executed. This ensures that the principal device initiates access requests only within the capabilities granted to it by the object device, and avoids initiating access requests outside of those capabilities. This increases the probability of the access request being responded to and reduces ineffective communication between devices.

[0251] In other embodiments, the host device may also execute subsequent steps directly after generating an access request.

[0252] S103, the main device requests the user to grant the necessary permissions for the access request generated by the main device.

[0253] In some embodiments, after the host device generates an access request, it can directly execute S103.

[0254] In other embodiments, after the primary device generates an access request, it can execute S103, provided that the callee and / or the first resource are sensitive resources. This ensures that when sensitive resources in the object device are accessed, user authorization can be obtained, thereby guaranteeing the security of user data. Sensitive resources can refer to resources that, if leaked, would pose a significant risk to user privacy, such as resources with a privacy level exceeding a threshold. Sensitive resources can include hardware resources, software resources, and stored data in electronic devices. Hardware resources can include, for example, cameras, audio devices, displays, etc. Software resources can include, for example, memory resources, computing power (e.g., beautification algorithms, audio and video encoding / decoding capabilities), network capabilities, location functions, highly confidential apps (e.g., banking apps), etc. Stored data can include, for example, stored user information, photos, videos, user passwords for logging into applications, etc.

[0255] In some other embodiments of this application, the main device may execute S103 first and then S102. That is, the main device may first request the user to grant permission, and after obtaining the permission, generate an access request.

[0256] An electronic device is authorized when it supports one or more authorization methods for user authorization. Similarly, a caller is authorized when it supports one or more authorization methods for user authorization.

[0257] Authorization methods may include, but are not limited to: pop-up authorization, fingerprint verification authorization, face verification authorization, voice command authorization, button authorization, etc. There are no restrictions here.

[0258] Whether an electronic device is eligible for authorization and the types of authorization methods it supports depend on its hardware and / or software configuration. For example, supporting pop-up authorization requires the electronic device to have a display screen. Supporting fingerprint verification authorization requires the electronic device to have a fingerprint sensor. Supporting facial verification authorization requires the electronic device to have a camera and facial recognition algorithm. Supporting voice command authorization requires the electronic device to have a microphone or other sound pickup device. Supporting button authorization requires the electronic device to have physical buttons.

[0259] Whether a caller has the necessary authorization depends on its own functionality. For example, if the caller can provide a user interface, it can support pop-up authorization. Or, if the caller can access a fingerprint sensor, it can support fingerprint verification authorization.

[0260] The permissions required for the access request generated by the subject device include: the permissions to invoke the callee in the object device, and / or, the permissions to access the first resource in the object device.

[0261] In some embodiments, the permissions required for the access request specifically include: the permission of the subject device to invoke the callee in the object device and / or to access the first resource.

[0262] In some embodiments, the permissions required for the access request specifically include: the caller's permission to invoke the callee in the object device and / or access the first resource.

[0263] In some embodiments, the permissions required for the access request specifically include: the permission of a caller in the subject device to invoke the callee in the object device and / or access the first resource.

[0264] In S103, the principal device can, during the execution of the caller, use authorization methods supported by both the principal device and the caller to request the user to grant the permissions required for the access request it generated. The different authorization methods are described below.

[0265] When the main device supports pop-up authorization, it can display a prompt message on the screen indicating the permissions required for the access request. The main device can then detect the user action on the screen and, in response, obtain the necessary permissions for the access request.

[0266] refer to Figure 5B , Figure 5B An example is shown of the user interface 51 displayed when the main device 200 requests user authorization using a pop-up authorization method.

[0267] User interface 51 displays window 506. Window 506 includes: a prompt message 506a, controls 506b and 506c. Prompt message 506a prompts the user to grant the necessary permissions to the access request generated by the main device 200. Prompt message 506a may be, for example, the text “The Gallery needs access to your image processing resources. After authorization, the following applications will use this permission: Image Processing Function Component (FA)”, where “Gallery” indicates the caller, “Image Processing Function Component (FA)” indicates the callee, and “Image Processing Resources” indicates that the first resource is a camera resource. Combined with the device providing the current user interface 51, the user… Figure 5A In the selected device option 505, the user can also learn that the main device is a tablet computer and the object device is the smartphone 1 corresponding to device option 505. In some other embodiments, the prompt information 506a may include information about the main device and the object device.

[0268] In other words, the prompt message 506a is used to prompt the user to grant the "Gallery" application in the main device 200 permission to call the image processing function component (FA) in the smartphone 1 (i.e., the object device 100) to access image processing resources.

[0269] The content of the 506a message is not limited to the form shown in the message. The specific content of the 506a message depends on the permissions required for the access request, and there are no restrictions here.

[0270] Control 506b can be used to listen for user operations. When the main device 200 responds to the user operation, it learns that it has not been able to obtain the permissions required for the access request generated by the main device 200.

[0271] Control 506c can be used to listen for user operations. In response to the user operation, the main device 200 successfully obtains the permissions required for the access request generated by the main device 200. Moreover, the permissions required for the access request obtained by the main device 200 are valid only once. After the access request is responded to, the main device 200 no longer has the permissions.

[0272] Control 506d can be used to listen for user actions. In response to the user action, the main device 200 successfully obtains the permissions required for the access request generated by the main device 200, and these permissions are permanent. That is, the permissions required for the access request obtained by the main device 200 are permanently valid.

[0273] like Figure 5B As shown, the main device 200 receives a user operation applied to the control 506c, obtains the permission of the "Gallery" in the main device 200 to call the image processing function component (FA) in the object device 100 and access the image processing resources, and the permission is valid only once.

[0274] refer to Figure 5E , Figure 5E An exemplary illustration shows the user interface 52 displayed when the main device 300 requests user authorization via a pop-up authorization method. The window 510 included in the user interface 52 can be referenced. Figure 5B The window 506 in the user interface 51 will not be described in detail here.

[0275] like Figure 5E As shown, the main device 300 can receive user operations applied to the control 510a. In response to the user operation, the main device 300 successfully obtains the permissions required for the access request generated by the main device 300, and the permissions are permanent.

[0276] When the main device supports fingerprint verification authorization, it can collect the user's fingerprint through a fingerprint sensor and compare the collected fingerprint with preset fingerprints. If the two fingerprints match, the main device obtains the permissions required for the access request. In some embodiments, the main device can preset multiple fingerprints and obtain permissions for access requests with different time limits when different preset fingerprints are collected.

[0277] When the main device supports facial verification authorization, it can capture the user's facial image through the camera and compare the captured facial image with a preset facial image. If the two match, the main device obtains the permissions required for the access request.

[0278] When the main device supports voice command authorization, it can collect the user's input voice commands through a microphone, receiver, or other sound pickup devices, and compare the collected voice commands with preset voice commands. If they match, the main device obtains the permissions required for the access request. In some embodiments, the main device can preset multiple voice commands, and obtain the permissions required for access requests with different time limits when different preset voice commands are collected.

[0279] When the main device supports button authorization, it can collect user press operations through physical buttons. If a preset press operation (such as a single press, long press, double press, etc.) is collected on the physical button, the main device obtains the permissions required for the access request. In some embodiments, the main device can preset multiple press operations and obtain the permissions required for access requests with different time limits when different preset press operations are collected.

[0280] In this embodiment, when a primary device requests a user to grant the permissions required for an access request generated by the primary device, if the permissions required in the access request include information about the primary device and / or the caller, the user can obtain more detailed information about the permissions required for the access request received by the current object device, and thus decide whether to grant the permissions. This ensures that the user fully understands the permissions required for the access request before performing the authorization operation, avoiding user errors or misauthorization, and ensuring data security on the object device.

[0281] As can be seen, in S103, the host device can respond to the received user operation and obtain the permissions required by the user-granted access request generated by the host device, and the permissions granted by the user may have an expiration time. The expiration time of the permission can include various types, not limited to those mentioned above. Figure 5B or Figure 5E The terms "one-time effective" and "permanently effective" shown in the document can also include more possibilities, such as "valid for one week," "valid for one month," or "valid in the first region," etc. There are no restrictions here.

[0282] In some embodiments, the principal device may execute S103 after each access request is generated. In other embodiments, after generating an access request, the principal device may first determine whether it has the necessary permissions for the access request, and if not, request permissions from the user through S103. This can reduce the interaction between the principal and guest devices and improve the efficiency of cross-device resource access in a distributed system.

[0283] Through S103, the principal device and the caller request the necessary permissions from the user for the access request. Regardless of whether the object device or the callee has the authorization conditions, as long as the principal device or the caller has the authorization conditions, the object device can obtain the necessary permissions for the access request. This ensures that the access request initiated by the caller can be successfully responded to, realizes resource calls between devices, and meets the user's actual needs.

[0284] S104, the main device sends the generated access request and the permission information granted by the user for the access request to the object device.

[0285] In the embodiments of this application, the permission information indicates one or more of the following: whether the main device has obtained the permission required for the access request, the permission required for the access request obtained by the main device, and the validity period of the permission obtained by the main device.

[0286] In some embodiments, the subject device can use capability-based access control technology to directly send the permission information required for the access request to the object device along with the access request itself. For example, the permission information required for the access request granted by the user can be carried in the access request. This avoids the time overhead of permission synchronization in centralized permission management mechanisms and improves the efficiency of resource access.

[0287] In some embodiments, the subject device may send an access request to the object device, and the permission information required for the access request granted by the user.

[0288] Executing S103-S104 above ensures that the main device initiates the access request only after obtaining the necessary permissions, thus guaranteeing the security of the entire call process.

[0289] In other embodiments of this application, the subject device may first send an access request to the object device. After receiving the access request, the object device may, after confirming that it does not have the permissions required for the access request, or directly send an authorization request to the subject device. This authorization request is used to request the user to apply for the permissions required for the access request. Subsequently, the subject device may respond to the authorization request, execute the operation S103, and send the permission information for the access request granted by the user to the object device. That is, the subject device can request the permissions required for the access request from the user upon being triggered by the object device, without having to actively request the permissions required for the access request from the user itself.

[0290] In some embodiments, the principal device can locate the object device corresponding to the access request based on the stored call relationship, and send the access request and the permission information required for the access request to the object device.

[0291] In some embodiments, after the principal device executes S104, it may also record or store the permission information obtained by the callee in the object device.

[0292] In optional step S105, the object device responds to the received access request by creating multiple instances of the callee.

[0293] Specifically, after receiving multiple access requests, the object device can activate different instances based on one or more of the following: the caller, the subject device, the caller's developer, the user account of the caller, or the subject device's account, etc. When one or more of these differ, the object device can activate different callee instances to provide services to the corresponding callers.

[0294] For example, if an application identified as "ID2" in the main device 200 and an application identified as "ID3" in the main device 300 simultaneously call an application identified as "ID1" in the object device 100, then the object device 100 can create two instances to provide services to the two callers respectively.

[0295] For example, if an application identified as "ID3" in the main device 300 and an application identified as "ID4" in the main device 400 simultaneously call an application identified as "ID1" in the object device 100, since the developers of the two callers are the same, the object device 100 can create an instance to provide services to both callers at the same time.

[0296] In some embodiments, if an instance of a callee providing services to a caller in the principal device already exists in the object device (i.e., the object device has previously created such an instance), then the object device does not need to execute S105 to recreate the instance. If an instance of a callee providing services to a caller in the principal device does not exist in the object device, then the object device executes S105 to create the instance.

[0297] Refer to the previous text Figure 5A and Figure 5D In the example, after receiving access requests from both the subject device 200 and the subject device 300, the object device 100 will create two instances of Image Processing Function Components (FA) to provide services to the subject device 200 and the subject device 300, respectively.

[0298] In some embodiments, the callee may be pre-installed on the object device. In other embodiments, the object device may download and install the callee from the network or directly from the subject device after receiving an access request from the object device.

[0299] When an object device creates an instance of a callee, it can assign a user ID (UID) and a process identifier (PID) to that instance. In some embodiments, the object device can assign different UIDs to different instances of the callee. In some embodiments, the object device can assign different PIDs to different instances of the callee. Therefore, the object device can distinguish different instances of the same callee by either the UID or the PID.

[0300] In some embodiments, after the object device creates an instance of the callee, it can save the calling relationship consisting of the caller and the instance of the callee. The specific content of the calling relationship can be found in the relevant description below. The object device can also synchronize some content of the calling relationship, such as the calling relationship ID, the UID and PID of the callee instance created for the caller in the subject device, etc., to the subject device to facilitate the subject device in storing the calling relationship.

[0301] In some embodiments, after receiving the permission information sent by the subject device, the object device may also record or store the permission information.

[0302] In some embodiments, the object device can query whether the subject device has permission to access the callee and / or access the first resource. Only if so will subsequent steps be executed. This reduces ineffective communication between the subject and object devices and improves the efficiency of resource retrieval.

[0303] Optional step S106: The object device is an instance of the callee, creating a routing proxy and revoking the proxy.

[0304] In this embodiment, the routing proxy and the revocation proxy can be applications, services, instances, processes, or threads.

[0305] In some embodiments, the object device may create a routing proxy and a revocation proxy for each instance of the callee, granting the callee instance access to the routing proxy and granting the revocation proxy the permissions required for the access request. For example, see [reference]. Figure 6A , Figure 6A The diagram illustrates the creation of instances, routing proxies, and revocation proxies by an object device 100, as well as the granting of appropriate permissions to the instances and each proxy. As shown, the object device 100 creates two instances of an Image Processing Function Component (FA), and creates a routing proxy and a revocation proxy for each of the two instances.

[0306] In other embodiments, the object device can create a revocation proxy for each instance of the callee, but the two instances share a single routing proxy. That is, the routing proxy can be reused. This reduces overhead in the object device and improves the efficiency of resource access. (See reference...) Figure 6B , Figure 6B The diagram illustrates the creation of an instance of another object device 100, as well as the routing and revocation of proxies, and the granting of appropriate permissions to the instance and each proxy.

[0307] In this embodiment, the routing proxy and revocation proxy can be created by the object device's system or by the object device through the callee; there is no limitation on this. Furthermore, the object device can use the caller's identity to create the routing proxy and revocation proxy, for example, using the caller's UID passed from the subject device. Having the object device's system create the routing proxy and revocation proxy prevents the callee from obtaining the permissions required for the access request, thereby preventing permission escalation or abuse and further protecting data security in electronic devices.

[0308] In some embodiments, if the object device has a routing proxy and a revocation proxy corresponding to the instance of the callee, the object device does not need to execute S106 to recreate the routing proxy and the revocation proxy. If the object device does not have a routing proxy and a revocation proxy corresponding to the instance of the callee, the object device may execute S106 to create the routing proxy and the revocation proxy.

[0309] In some embodiments, the routing proxy and revocation proxy corresponding to the same callee instance can be combined into a single proxy.

[0310] Through S106, the object device can create multiple instances of the callee and create a revocation proxy for each instance. The permissions required for each access request are granted to different revocation proxies. Such a revocation proxy can only obtain the permissions required for one access request. By using revocation proxies that are isolated from each other, the problems of permission mixing and permission expansion are avoided, which can ensure the data security in the object device and prevent data abuse and leakage.

[0311] S107, the object device grants the access permission to the routing agent to the instance of the callee, and grants the access request-revoked agent the permissions required for the access request.

[0312] After executing S107, the routing proxy corresponding to the same callee instance can access its corresponding revocation proxy, while the callee instance cannot access the revocation proxy. In other words, the access path in this embodiment can only be callee instance - routing proxy - revocation proxy - first resource.

[0313] S108, the object device runs an instance of the callee, accesses the routing proxy corresponding to the instance, finds the revocation proxy corresponding to the instance through the routing proxy, and accesses the first resource through the revocation proxy.

[0314] Specifically, since the instance of the callee has permission to access the routing proxy, the object device running the instance of the callee can access the routing proxy. Then, the object device uses the routing proxy to find the revocation proxy corresponding to the instance of the callee. Since the revocation proxy has the permissions required for the access request, the object device can access the first resource through the revocation proxy. When the permissions required for the access request include the permission to invoke the callee, this can be seen as including the permission to invoke the callee to perform various operations, and therefore also including the permission to access the first resource.

[0315] As can be seen, when executing S108, the object device grants the instance, routing proxy, and revocation proxy of the callee their respective permissions, and when responding to access requests, the instance, routing proxy, and revocation proxy of the callee directly perform permission checks, without the need for additional permission verification through the access control module, thus reducing time overhead.

[0316] In this embodiment of the application, different revocation agents are isolated from each other, so there will be no situation where the permissions of each revocation agent are mixed or expanded.

[0317] In some embodiments, the object device responds to an access request to access a first resource, which may specifically include one or more of the following:

[0318] 1. The object device runs as an instance of the callee created by the caller, accesses the first resource to perform a series of operations, such as displaying a video call interface on a screen, capturing images through a camera, performing computational operations, image processing, obtaining location information, etc.

[0319] 2. The object device sends the access result of accessing the first resource to the subject device. For example, it sends the image captured by the camera to the subject device so that the subject device can send it to the other end device with which it is having a video call. Or it sends the calculation result and the obtained location information to the subject device, etc.

[0320] 3. The object device receives data sent by the subject device and uses that data to access the first resource and perform a series of operations. For example, the object device can receive an image captured by the other end of a video call sent by the subject device and display the image on the video call interface of the display screen.

[0321] Here, the operation performed by the object device when responding to an access request to access the first resource can be determined by the object device by default, by the user on the object device side, or by the access request sent by the subject device side; there are no restrictions here.

[0322] For example, refer to Figure 5C , Figure 5C This is the user interface 51 displayed by the main device 200 after receiving the access result from the object device 100 accessing the first resource. The main device 200 can first... Figure 5A Image 504 is sent to object device 100. Image 504 can be carried in an access request. Object device 100 can then run an instance of the image processing function component (FA) created for the "library" in subject device 200, and access the image processing resources in object device 100 through specific operations in S107. The access result after processing image 504 by the image processing resources is then sent to subject device 200. Figure 5C The main device 200 can display the image 506 processed by the object device 100 in the user interface 51 based on the access result. Clearly, in comparison... Figure 5A Images 504 and 506 in the image have higher resolution. The object device 100's adjustment of the resolution of image 504 can be selected by the user on the object device side, or it can be performed by default on the object device. In some embodiments, the user interface 51 may also display a prompt message 507 to indicate the result of the resource call.

[0323] Similarly, refer to Figure 5F , Figure 5FThis is the user interface 52 displayed by the main device 300 after receiving the access result from the object device 100 accessing the first resource. The main device 300 can first... Figure 5D Image 508 is sent to object device 100. Image 508 can be carried in an access request. Object device 100 can then run an instance of the image processing function component (FA) created for the "library" in subject device 300, and access the image processing resources in object device 100 through specific operations in S107. The access result after processing image 508 by the image processing resources is then sent to subject device 300. Figure 5F The main device 300 can display the image 511 processed by the object device 100 in the user interface 52 based on the access result. Clearly, in comparison... Figure 5D The images of people in images 508 and 511 have undergone slimming and reshaping processing. The slimming and reshaping processing of the image of people in image 508 by the object device 100 can be selected by the user on the object device side, or it can be performed by default on the object device. In some embodiments, the user interface 52 may also display a prompt message 512 to indicate the result of the resource call.

[0324] S109, The object device revokes the permissions required for the access request.

[0325] In this application embodiment, the object device may revoke the permissions required by the access request passed by the subject device in any of the following circumstances:

[0326] 1. If the permission information transmitted by the subject device includes time-limited information, the object device can revoke the permissions required for the access request based on the time-limited information indicated by the time-limited information.

[0327] For example, if the expiration information indicates a one-time validity period, the object device can revoke the permissions required by the access request after successfully responding to the access request, i.e., after ending access to the first resource. For example, in Figures 5A-5C In the example, after receiving an access request from the subject device 200, the object device 100 can immediately revoke the permissions required by the access request after responding to the access request.

[0328] For example, if the timeliness information indicates that it is valid for the first time, the object device can revoke the permissions required for the access request immediately after receiving the timeliness information.

[0329] For example, if the timeliness information indicates that it is valid in the first region, the object device can revoke the permissions required for the access request if it is located in a region other than the first region.

[0330] 2. After successfully responding to the access request, i.e., after ending access to the first resource, the object device can revoke the permissions required for the access request according to its own permission revocation policy.

[0331] The permission revocation policy in the object device may include, but is not limited to: immediately revoking the permissions required for the access request, revoking the permissions required for the access request after a second time following a successful response to the access request, revoking the permissions required for the access request when the instance of the callee has not accessed the first resource in the object device for a preset period of time, or revoking the permissions required for the access request under other conditions, etc.

[0332] The second method allows the object device to revoke permissions after successfully responding to an access request, without needing to transmit expiration information. This avoids situations where the permission expires before the resource call is completed, thus achieving the goal of accurately revoking permissions according to actual user needs.

[0333] Specifically, in the embodiments of this application, the object device can revoke the permissions required for the access request by any one or more of the following:

[0334] 1. The object device revokes the permissions required to grant the access request to the revocation agent.

[0335] After the object device revoks the permissions required for the access request granted to the revocation agent, the revocation agent will no longer be able to access the first resource. The instance of the callee and the routing agent will also be unable to access the first resource through the revocation agent, thus achieving the purpose of revoking permissions.

[0336] 2. The object device terminates the routing agent and / or cancels the agent.

[0337] Terminating a routing proxy and / or revoking a proxy can mean that the object device completely clears the data related to the routing proxy and / or revoking proxy, so that the routing proxy and / or revoking proxy no longer exist on the object device. This prevents subsequent instances of the called object from accessing the primary resource through the routing proxy and revoking proxy, thus achieving the purpose of revoking permissions.

[0338] In this embodiment, accessing the first resource via a routing proxy and a revocation proxy avoids directly granting the permissions required for the access request to the instance of the callee. Even if the instance of the callee re-transfers its permissions to other callees, the re-transferred permissions will become invalid after executing S108, thus achieving the purpose of accurately revoking permissions. Furthermore, through the routing proxy and revocation proxy, the object device does not need to store a large amount of permission delegation information, saving the object device's storage resources.

[0339] exist Figure 4In the method shown, the object device can also manage the lifecycle of the instance of the callee created for the caller in the subject device. In some embodiments, the object device can stop running or destroy the instance after it has been running and successfully responded to an access request, or it can stop running or destroy the instance after a preset time, or it can stop running or destroy the instance if it has not accessed any resources on the object device for a certain period of time. Stopping an instance means that the instance still exists on the object device, but it is not in a running state. Destroying an instance means that the object device deletes all data related to the instance, and the instance no longer exists on the object device.

[0340] exist Figure 4 In the access control method shown:

[0341] An object device (e.g., object device 100) may be referred to as a first device, a subject device (e.g., subject device 200) may be referred to as a second device, and another subject device (e.g., subject device 300) may be referred to as a third device.

[0342] The caller in the second device, such as the "image library" in the main device 200, can be called the first caller, and the caller in the third device, such as the "image library" in the main device 300, can be called the second caller.

[0343] An access request sent by a second device to a first device can be referred to as a first access request. An access request sent by a third device to a first device can be referred to as a second access request. The permissions required for the first access request can be referred to as first permissions. The permissions required for the second permission information can be referred to as second permissions.

[0344] The permission information sent by the second device to the first device can be referred to as the first permission information. The permission information sent by the third device to the first device can be referred to as the second permission information.

[0345] The instance of the callee that the first device runs in response to the first access request may be referred to as the first instance. The instance of the callee that the first device runs in response to the second access request may be referred to as the second instance.

[0346] The routing agent and the revocation agent operated by the first device in response to the first access request can be referred to as the first routing agent and the first revocation agent, respectively. When the first routing agent and the first revocation agent are combined into one agent, this agent can be referred to as the first agent.

[0347] The routing agent and the revocation agent operated by the first device in response to the second access request can be referred to as the second routing agent and the second revocation agent, respectively. When the second routing agent and the second revocation agent are combined into one agent, this agent can be referred to as the second agent.

[0348] Not limited to the distributed systems exemplified above, Figure 4 The method shown can also be applied to a single electronic device. For example, this electronic device may contain one or more callers and callees, and may act as both the subject and object device. The electronic device can generate one or more access requests to invoke the same callee, whereby the caller invokes the callee to access a first resource within the electronic device. The timing and method of generating these access requests can be found in [reference needed]. Figure 4 The description of the main device generating the access request in S102. After the electronic device generates the access request, it can execute... Figure 4 The difference between S103-S109 in the method shown is that... Figure 4 The communication process between the secondary equipment and the primary equipment can be omitted.

[0349] Furthermore, the electronic device can create routing and revocation proxies through the caller or the system. This prevents the callee from obtaining the permissions required for the access request, thus avoiding privilege escalation or abuse and protecting the data security within the electronic device. Moreover, the electronic device can use the caller's identity to create the routing and revocation proxies; for example, it can use the caller's UID to create these two proxies.

[0350] For details on how a single electronic device can implement the access control method provided in the embodiments of this application, please refer to [reference needed]. Figure 4 The relevant descriptions will not be repeated here.

[0351] refer to Figure 8 , Figure 8 This example illustrates a simplified process for implementing the access control method provided in the embodiments of this application using a single electronic device based on a binder. Figure 8 As shown, the electronic device includes user space and kernel space. The user space includes the caller (e.g., APP1) and the callee (e.g., APP2), and the kernel space includes the binder driver.

[0352] like Figure 8 As shown, the process may include the following steps:

[0353] 1. APP1 notifies the system to create or revoke a routing proxy, and stipulates that only those with P2 permissions can access the routing proxy.

[0354] 2. APP1 requests to call APP2.

[0355] 3. The binder driver passes P2 permission to the routing proxy and P1 permission to the revocation proxy through processing commands. P1 permission is the permission required by APP1 when requesting to call APP2, and this permission is used to access the primary resource.

[0356] 4. APP2 responds to APP1's request and initiates a request to call the first resource.

[0357] 5. The system (such as the application scheduling and management module) starts the routing proxy based on APP2's request. Because APP2 already has P2 permissions, it can start the routing proxy.

[0358] 6. The routing proxy will directly forward the request initiated by APP2 to the cancellation proxy.

[0359] 7. Revoke the agent's call to the first resource. Since the agent already has P1 privileges, it can call the first resource.

[0360] After finishing calling the first resource, APP1 can request the system to delete or APP1 can delete the revocation proxy and / or routing proxy itself. Alternatively, it can revoke the P1 permission for revocation of the proxy through the binder driver to complete the permission revocation.

[0361] In a distributed system, it is also possible to base it on and Figure 8 Similarly, permissions can be granted and revoked using Binder, but the detailed implementation will not be elaborated here.

[0362] In a standalone device, electronic devices can precisely and flexibly revoke the permissions required for an access request through routing proxies and revocation proxies. For details, please refer to the relevant descriptions when implementing this access control method in a distributed system.

[0363] When the access control method for precisely revoking permissions provided in this application embodiment is executed in a standalone device, one caller in the electronic device can be referred to as the first caller, and the other caller can be referred to as the second caller. The access request generated by the electronic device when running the first caller for calling the callee and accessing the first resource can be referred to as the first access request. The access request generated by the electronic device when running the second caller for calling the callee and accessing the first resource can be referred to as the second access request. The permission required for the first access request can be referred to as the first permission. The permission required for the second permission information can be referred to as the second permission.

[0364] The instance of the callee executed by an electronic device in response to a first access request may be referred to as the first instance. The instance of the callee executed by a third device in response to a second access request may be referred to as the second instance.

[0365] The routing agent and revocation agent operated by an electronic device in response to a first access request can be referred to as the first routing agent and the first revocation agent, respectively. When the first routing agent and the first revocation agent are combined into one agent, that agent can be referred to as the first agent.

[0366] The routing agent and revocation agent operated by an electronic device in response to a second access request can be referred to as a second routing agent and a second revocation agent, respectively. When the second routing agent and the second revocation agent are combined into one agent, that agent can be called a second agent.

[0367] refer to Figure 7A , Figure 7A A schematic diagram of the software structure of the main device provided in an embodiment of this application. The main device may be... Figure 4 The main device 200 or main device 300 in the embodiments.

[0368] like Figure 7A As shown, the main device may include the following modules: application information management module, permission application module, permission delegation module, call relationship management module, and call relationship database. Among them:

[0369] The application information management module is used to manage information such as names of various apps and functional components installed on the main device. This module also synchronizes the information of apps and functional components on the main device to other devices, and simultaneously receives synchronized app and functional component information from other devices (such as guest devices).

[0370] The permission request module is used to request the user for the permissions required to access the device when the main device generates an access request for calling the callee in the object device.

[0371] The permission delegation module is used to send the permission information obtained by the permission request module to the object device according to the calling relationship. In some embodiments, the permission delegation module is used to send the permission information obtained by the permission request module and the access request generated by the subject device to the object device simultaneously.

[0372] The call relationship management module is responsible for maintaining the call relationship consisting of the caller and the callee instances that provide services to the caller, and storing it in the call relationship database.

[0373] The call relationship database stores the call relationships between caller and callee instances. This call relationship includes: a call relationship ID, instance information of the callee, and information about each caller that invoked that instance.

[0374] The call relationship ID can be assigned by the subject device. For the same call relationship, the object device and the subject device can share the same call relationship ID. This call relationship ID can be carried in the access request sent to the object device, and is assigned by the subject device before being sent to the object device.

[0375] The instance information of the callee may include one or more of the following: the device ID of the object device, the APP ID of the callee, the UID and PID of the instance. The PID is the identity identifier of the instance; each time an electronic device runs an instance, it assigns a unique PID to that instance. The PID and UID can be synchronized from the object device to the host device.

[0376] The caller information includes the caller's application ID (APP ID), and may also include one or more of the following: the device ID of the main device (device ID), the caller's developer signature, the caller's user ID (UID), and the main device's account ID. Among these:

[0377] APP ID is used to identify an app or functional component.

[0378] Device ID is used to identify a device. Device ID can be, for example, the device's name, serial number, media access control (MAC) address, etc.

[0379] Developer signature, used to identify the developer.

[0380] A UID is used to identify the user to whom an app or feature belongs. Typically, electronic devices assign different UIDs to different installed apps or features for differentiation. In some embodiments, an electronic device may assign the same UID to various apps or features developed by the same developer. The same app or feature may have different UIDs on different electronic devices.

[0381] The account ID is used to identify the user currently logged into the electronic device; for example, it could be a Huawei account.

[0382] Figure 7A This is merely an illustrative example; the main device provided in this application embodiment may also include more or fewer modules, and no limitation is made here.

[0383] Figure 7A The various modules in the main equipment mentioned can be located in Figure 3B The electronic device shown includes the application layer, application framework layer, system service layer, kernel layer, etc., without limitation.

[0384] refer to Figure 7B , Figure 7B This is a schematic diagram of the software structure of the object device provided in an embodiment of this application. The object device can be... Figure 4 The object device 100 in the embodiment.

[0385] like Figure 7B As shown, the object device may include the following modules: application information management module, instance management module, permission delegation module, routing proxy management module, revocation proxy management module, delegation revocation management module, call relationship management module, and call relationship database. Among them:

[0386] The application information management module is used to manage information such as names of the various apps and functional components installed on the client device. This module also synchronizes the information of the client's apps and functional components to other devices, and simultaneously receives synchronized information of apps and functional components from other devices (such as the client device).

[0387] The instance management module is responsible for dynamically enabling instances of the callee based on the caller's information, thus providing services to that caller. Specifically, the instance management module can enable different instances of the callee for different callers. The instance management module is also used to manage the lifecycle of each instance, such as starting, stopping, destroying, and restarting.

[0388] The permission delegation module receives the permission information required for an access request sent by the primary device. It then grants the permissions required by the access proxy module to the callee, and conversely, grants the necessary permissions to the proxy module. The proxy module can include proxy revocation and routing proxy functions.

[0389] A routing proxy management module is used to create routing proxies. In some embodiments, the routing proxy management module can create different routing proxies in response to different access requests. In other embodiments, the routing proxy management module can create a single routing proxy to respond to all access requests received by the object device.

[0390] The revocation proxy management module is used to create revocation proxies. In some embodiments, the revocation proxy management module can create different revocation proxies in response to different access requests.

[0391] The delegation revocation management module is used to revoke the permissions granted to the revocation agent, or terminate the revocation agent and / or routing agent, when required by the object device.

[0392] The call relationship management module is responsible for maintaining the call relationship consisting of the caller and the callee instances that provide services to the caller, and storing it in the call relationship database.

[0393] The call relationship database stores the call relationships between caller and callee instances. This relationship includes: a call relationship ID, instance information of the callee, and information about each caller that invoked that instance. For details on this call relationship, please refer to [reference needed]. Figure 7A Description of the main equipment.

[0394] Figure 7B This is merely an illustrative example; the object device provided in the embodiments of this application may also include more or fewer modules, and no limitation is made here.

[0395] Figure 7B The various modules in the mentioned object equipment can be located in Figure 3B The electronic device shown includes the application layer, application framework layer, system service layer, kernel layer, etc., without limitation.

[0396] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0397] 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 program instructions are loaded and executed on a computer, all or part of the processes or functions described in 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 website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) 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 medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0398] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0399] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.

Claims

1. An access control method for revoking permissions, characterized in that, The method is applied to a communication system including a first device and a second device. The first device has a callee installed, and the second device has a first caller installed. The callee and the first caller are application programs (APP) or functional components. The APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function. The method includes: The second device sends a first access request and first permission information to the first device. The first access request is used by the first caller to invoke the callee to access a first resource in the first device. The first permission information indicates a first permission, which includes the permission to invoke the callee and / or the permission to access the first resource. In response to the first access request, the first device grants the first permission to the first agent and grants the callee permission to access the first agent, wherein the first agent is a service, process, or thread; The first device runs the callee, accesses the first agent, and accesses the first resource through the first permissions possessed by the first agent; The first device performs the following actions based on the validity period of the first permission indicated by the first permission information, or after successfully responding to the first access request and accessing the first resource, or after the second time after ending access to the first resource: terminating the first agent, or revoking the first permission possessed by the first agent.

2. The method according to claim 1, characterized in that, The validity period of the first permission indicated by the first permission information is any one of the following: valid only once, valid within a first time period, or valid within a first region; The first device terminates the first agent based on the validity period of the first permission indicated by the first permission information, or the first device revokes the first permission possessed by the first agent, specifically including: If the validity period is one-time validity, the first device terminates the first agent or revokes the first permission possessed by the first agent after ending access to the first resource; If the validity period is valid within the first time period or within the first region, then after receiving the first permission information at the first time period, or when located outside the first region, the first device terminates the first agent or revokes the first permission possessed by the first agent.

3. The method according to claim 1, characterized in that, The first device grants the callee permission to access the first agent, specifically including: the first device grants the callee a first instance permission to access the first agent; The first device runs the callee and accesses the first agent, specifically including: the first device runs the first instance and accesses the first agent; The communication system further includes a third device, wherein a second caller is installed in the third device, and the second caller is the APP or the functional component; the method further includes: The third device sends a second access request and second permission information to the first device. The second access request is used by the second caller to call the callee to access the first resource. The second permission information indicates a second permission, which includes the permission to call the callee and / or the permission to access the first resource. In response to the second access request, the first device grants the second permission to the second agent, and grants the permission to access the second agent to the second instance of the callee, wherein the second agent is a service, process, or thread; The first device runs the second instance, accesses the second agent, and accesses the first resource through the second permissions possessed by the second agent; Wherein, the first instance and the second instance are processes or threads running in random access memory (RAM), the second instance is different from the first instance, and the second instance and the first instance are isolated from each other.

4. The method according to claim 3, characterized in that, Before the first device grants access to the first agent to the first instance of the callee, the method further includes: The first device responds to the first access request and creates the first instance.

5. The method according to any one of claims 1-4, characterized in that, The first agent includes: a first routing agent and a first revocation agent; the first routing agent and the first revocation agent are services, processes, or threads; The first device grants the first permission to the first agent and grants the permission to access the first agent to the callee, specifically including: the first device grants the first permission to the first revocation agent and grants the permission to access the first routing agent to the callee; The first device runs the callee, accesses the first agent, and accesses the first resource through the first permission possessed by the first agent. Specifically, the first device runs the callee, accesses the first revocation agent through the first routing agent, and accesses the first resource through the first permission possessed by the first revocation agent. The first device terminates the first agent, or the first device revokes the first permission possessed by the first agent, specifically including: the first device terminates the first routing agent and / or the first revocation agent, or the first device revokes the first permission possessed by the first revocation agent.

6. The method according to any one of claims 1-4, characterized in that, Before the first device grants the first permission to the first agent in response to the first access request, the method further includes: The first device responds to the first access request and creates the first proxy.

7. The method according to any one of claims 1-4, characterized in that, The first permission specifically includes: The second device invokes the permissions of the callee, and / or the second device has the permission to access the first resource; And / or, The first caller invokes the callee's permissions, and / or the first caller has the permission to access the first resource.

8. The method according to any one of claims 1-4, characterized in that, The second device sends a first access request and first permission information to the first device, specifically including: The second device sends a first access request to the first device, the first access request carrying first permission information.

9. The method according to any one of claims 1-4, characterized in that, Before the second device sends the first permission information to the first device, the method further includes: The second device outputs a prompt message, which is used to prompt for the first permission; The second device receives the user's operation.

10. An access control method for revoking permissions, characterized in that, The method is applied to an electronic device, which has a callee installed in it. The callee is an application program (APP) or a functional component. The APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function. The method includes: The electronic device receives a first access request and first permission information sent by the second device. The first access request is used by a first caller in the second device to call the callee to access a first resource in the electronic device. The first permission information indicates a first permission, which includes the permission to call the callee and / or the permission to access the first resource. The first caller is the APP or the functional component. In response to the first access request, the electronic device grants the first permission to the first agent and grants the callee permission to access the first agent, wherein the first agent is a service, process, or thread. The electronic device runs the callee, accesses the first agent, and accesses the first resource through the first permissions possessed by the first agent; The electronic device performs the following actions based on the validity period of the first permission indicated by the first permission information, or after successfully responding to the first access request and accessing the first resource, or after the second time after ending access to the first resource: terminating the first agent, or revoking the first permission possessed by the first agent.

11. The method according to claim 10, characterized in that, The validity period of the first permission indicated by the first permission information is any one of the following: valid only once, valid within a first time period, or valid within a first region; The electronic device terminates the first agent based on the validity period of the first permission indicated by the first permission information, or the electronic device revokes the first permission possessed by the first agent, specifically including: If the validity period is one-time, the electronic device terminates the first agent or revokes the first permission possessed by the first agent after ending access to the first resource; If the validity period is valid within the first time period or within the first area, then the electronic device, after receiving the first permission information at the first time period, or when located outside the first area, terminates the first agent or revokes the first permission possessed by the first agent.

12. The method according to claim 10, characterized in that, The electronic device grants the callee permission to access the first agent, specifically including: the electronic device grants the callee's first instance permission to access the first agent; The electronic device running the callee and accessing the first agent specifically includes: the electronic device running the first instance and accessing the first agent; The method further includes: The electronic device receives a second access request and second permission information sent by a third device. The second access request is used by a second caller in the third device to call the callee to access the first resource. The second permission information indicates a second permission, which includes the permission to call the callee and / or the permission to access the first resource. The second caller is the APP or the functional component. In response to the second access request, the electronic device grants the second permission to the second agent and grants the permission to access the second agent to the second instance of the callee, wherein the second agent is a service, process, or thread; The electronic device runs the second instance, accesses the second agent, and accesses the first resource through the second permissions possessed by the second agent; Wherein, the first instance and the second instance are processes or threads running in random access memory (RAM), the second instance is different from the first instance, and the second instance and the first instance are isolated from each other.

13. The method according to claim 12, characterized in that, Before the electronic device grants access to the first agent to the first instance of the callee, the method further includes: The electronic device responds to the first access request and creates the first instance.

14. The method according to any one of claims 10-13, characterized in that, The first agent includes: a first routing agent and a first revocation agent; the first routing agent and the first revocation agent are services, processes, or threads; The electronic device grants the first permission to the first agent and grants the permission to access the first agent to the callee, specifically including: the electronic device grants the first permission to the first revocation agent and grants the permission to access the first routing agent to the callee; The electronic device runs the callee, accesses the first agent, and accesses the first resource through the first permission possessed by the first agent. Specifically, the electronic device runs the callee, accesses the first revocation agent through the first routing agent, and accesses the first resource through the first permission possessed by the first revocation agent. The electronic device may terminate the first agent, or the electronic device may revoke the first permission possessed by the first agent, specifically including: the electronic device may terminate the first routing agent and / or the first revocation agent, or the electronic device may revoke the first permission possessed by the first revocation agent.

15. The method according to any one of claims 10-13, characterized in that, Before the electronic device grants the first permission to the first agent in response to the first access request, the method further includes: The electronic device responds to the first access request by creating the first proxy.

16. The method according to any one of claims 10-13, characterized in that, The first permission specifically includes: The second device invokes the permissions of the callee, and / or the second device has the permission to access the first resource; And / or, The first caller invokes the callee's permissions, and / or the first caller has the permission to access the first resource.

17. The method according to any one of claims 10-13, characterized in that, The electronic device receives a first access request and first permission information sent by the second device, specifically including: The electronic device receives a first access request sent by the second device, the first access request carrying first permission information.

18. An access control method for revoking permissions, characterized in that, The method is applied to an electronic device, which has a first caller and a callee installed thereon. The first caller and the callee are application programs (APPs) or functional components. The APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function. The method includes: The electronic device generates a first access request and obtains a first permission. The first access request is used by the first caller to call the callee to access a first resource in the electronic device. The first permission includes the permission to call the callee and / or the permission to access the first resource. In response to the first access request, the electronic device grants the first permission to the first agent and grants the callee permission to access the first agent. The electronic device runs the callee, accesses the first agent, and accesses the first resource through the first permissions possessed by the first agent; The electronic device performs the following actions based on the validity period of the first permission indicated by the first permission information, or after successfully responding to the first access request and accessing the first resource, or after the second time after ending access to the first resource: terminating the first agent, or revoking the first permission possessed by the first agent.

19. The method according to claim 18, characterized in that, The validity period is any one of the following: valid only once, valid within the first time period, or valid within the first region; The electronic device terminates the first agent based on the validity period of the first permission indicated by the first permission information, or the electronic device revokes the first permission possessed by the first agent, specifically including: If the validity period is one-time, the electronic device terminates the first agent or revokes the first permission possessed by the first agent after ending access to the first resource; If the validity period is valid within the first time period or within the first area, then the electronic device, after receiving the first permission information at the first time period, or when located outside the first area, terminates the first agent or revokes the first permission possessed by the first agent.

20. The method according to claim 18, characterized in that, The electronic device also has a second caller installed, which is the APP or the functional component; The electronic device grants the callee permission to access the first agent, specifically including: the electronic device grants the callee's first instance permission to access the first agent; The electronic device running the callee and accessing the first agent specifically includes: the electronic device running the first instance and accessing the first agent; The method further includes: The electronic device generates a second access request and obtains a second permission. The second access request is used by the second caller to invoke the callee to access the first resource. The second permission includes the permission to invoke the callee and / or the permission to access the first resource. In response to the second access request, the electronic device grants the second permission to the second agent and grants the permission to access the second agent to the second instance of the callee, wherein the second agent is a service, process, or thread; The electronic device runs the second instance, accesses the second agent, and accesses the first resource through the second permissions possessed by the second agent; Wherein, the first instance and the second instance are processes or threads running in random access memory (RAM), the second instance is different from the first instance, and the second instance and the first instance are isolated from each other.

21. The method according to claim 20, characterized in that, Before the electronic device grants access to the first agent to the first instance of the callee, the method further includes: The electronic device responds to the first access request and creates the first instance.

22. The method according to any one of claims 18-21, characterized in that, The first agent includes: a first routing agent and a first revocation agent; the first routing agent and the first revocation agent are services, processes, or threads; The electronic device grants the first permission to the first agent and grants the permission to access the first agent to the callee, specifically including: the electronic device grants the first permission to the first revocation agent and grants the permission to access the first routing agent to the callee; The electronic device runs the callee, accesses the first agent, and accesses the first resource through the first permission possessed by the first agent. Specifically, the electronic device runs the callee, accesses the first revocation agent through the first routing agent, and accesses the first resource through the first permission possessed by the first revocation agent. The electronic device may terminate the first agent, or the electronic device may revoke the first permission possessed by the first agent, specifically including: the electronic device may terminate the first routing agent and / or the first revocation agent, or the electronic device may revoke the first permission possessed by the first revocation agent.

23. The method according to any one of claims 18-21, characterized in that, Before the electronic device grants the first permission to the first agent in response to the first access request, the method further includes: The electronic device responds to the first access request by creating the first proxy.

24. The method according to any one of claims 18-21, characterized in that, The first permission specifically includes: The electronic device invokes the permissions of the invoked party, and / or the electronic device accesses the first resource; And / or, The first caller invokes the callee's permissions, and / or the first caller has the permission to access the first resource.

25. The method according to any one of claims 18-21, characterized in that, Before the electronic device obtains the first permission, the method further includes: The electronic device outputs a prompt message, which is used to prompt for the first permission; The electronic device receives user input.

26. An electronic device, characterized in that, include: A memory, and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 10-25.

27. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 10-25.

28. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 10-25.

29. A communication system, characterized in that, The communication system includes: a first device and a second device, wherein the first device is used to perform the method as described in any one of claims 10-17.

Images