A method, electronic device and system for access control

Abstract

The application discloses a method for access control, which can support different instances running in different sandboxes when a called party provides services for different calling parties, and data between different sandboxes is kept isolated, thereby solving the problems of data abuse, misuse or leakage of each calling party and guaranteeing data security.

Description

[0001] Cross Reference to Related Applications

[0002] The present application claims priority to the Chinese patent application No. 202110307174.2, filed on March 23, 2021, and entitled "Method, Electronic Device and System for Access Control", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present application relates to the technical field of computer, and in particular to a method, an electronic device and a system for access control. BACKGROUND

[0004] An application (APP) in a terminal operating system (OS) can apply for access authorization of sensitive resources in the form of an independent subject to a user, and can provide corresponding services for the user after the user's authorization. When an APP calls the service of another APP, the called APP can provide services for the caller APP. If the called APP is called by different caller APPs, different data generated by different callers will be stored in the called APP, and the called APP can access the data generated by different callers at will, which makes the data security of the caller APPs not guaranteed. SUMMARY

[0005] The present application provides a method, an electronic device and a system for access control, which solves the problem of misuse, abuse or leakage of data of different callers in the called APP, and guarantees the data security of different callers.

[0006] The above and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the drawings.

[0007] In a first aspect, the embodiments of the present application provide a method for access control, which is applied to a communication system, the communication system comprising a first device, a second device and a third device, wherein the first device is installed with a first caller, the second device is installed with a called party, and the third device is installed with a second caller; the first caller, the called party and the second caller are application programs or function components, the application program is a program entity for realizing multiple functions, and the function component is a program entity for realizing a single function.

[0008] The method comprises: the first device sending a first request to the second device, the first request carrying: the first invoker, the callee, and indication information of a first service; in response to the first request, the second device running a first instance in a first sandbox, the first instance being an instance of the callee, the first instance being configured to provide the first service for the first invoker; the third device sending a second request to the second device, the second request carrying: the second invoker, the callee, and indication information of a second service; in response to the second request, the second device running a second instance in a second sandbox, the second instance being an instance of the callee, the second instance being configured to provide the second service for the second invoker, the second sandbox being different from the first sandbox.

[0009] When the callee provides services for different invokers, the method of the first aspect can run different instances in different sandboxes, for example, the callee on the second device can run a first instance in a first sandbox to provide a first service for a first invoker on the first device, and the callee on the second device can run a second instance in a second sandbox to provide a second service for a second invoker on the third device. Data between different sandboxes is kept isolated, which can more effectively reduce the risk of misuse, confusion, misuse, or leakage of data of each invoker, and ensure data security.

[0010] In combination with the first aspect, in some embodiments, the method can further comprise: the first device initiating a third request to the second device, the third request carrying: the first invoker, the callee, and indication information of a third service; in response to the third request, the second device running the first instance in the first sandbox, the first instance being further configured to provide the third service for the first invoker, or the second device running a third instance in the first sandbox, the third instance being configured to provide the third service for the first invoker.

[0011] In combination with the first aspect, in some embodiments, the method can further comprise: the first device initiating a fourth request to the second device, the fourth request carrying: the third invoker, the callee, and indication information of a fourth service, wherein the third invoker is installed in the first device, and the third invoker is an application program APP or a functional component; in response to the fourth request, the second device running the first instance in the first sandbox, the first instance being further configured to provide the fourth service for the third invoker, or the second device running a third instance in the first sandbox, the third instance being configured to provide the fourth service for the third invoker.

[0012] With reference to the first aspect, in some embodiments, the method can further include: the fourth device initiating a fifth request to the second device, the fifth request carrying: the first invoker, the callee, and indication information of a fifth service, wherein the first invoker is installed in the fourth device; in response to the fifth request, the second device running the first instance in the first sandbox, the first instance further configured to provide the fifth service for the first invoker of the fourth device, or the second device running a third instance in the first sandbox, the third instance configured to provide the fourth service for a third invoker.

[0013] With reference to the first aspect, in some embodiments, the first invoker and the second invoker are the same.

[0014] With reference to the first aspect, in some embodiments, the first device and the third device are the same device.

[0015] With reference to the first aspect, in some embodiments, before the second device runs the first instance, the method further includes: the second device detecting whether the first sandbox exists, and if not, the second device creating the first sandbox; before the second device runs the second instance, the method further includes: the second device detecting whether the second sandbox exists, and if not, the second device creating the second sandbox.

[0016] With reference to the first aspect, in some embodiments, the second device running the first instance in the first sandbox includes: the second device creating the first instance and running the first instance in the first sandbox.

[0017] The second device running the second instance in the second sandbox includes: the second device creating the second instance and running the second instance in the second sandbox.

[0018] With reference to the first aspect, in some embodiments, the method can further include: after the second device creates the first instance, the second device storing a first invocation relationship, the first invocation relationship including: information of the first invoker, information of the first instance, and an identifier of the first invocation relationship; after the second device creates the second instance, the second device storing a second invocation relationship, the second invocation relationship including: information of the second invoker, information of the second instance, and an identifier of the second invocation relationship.

[0019] With reference to the first aspect, in some embodiments, after the first device sends the first request to the second device, the method further includes: the first device storing the first invocation relationship; after the third device sends the second request to the second device, the method further includes: the third device storing the second invocation relationship.

[0020] With reference to the first aspect, in some embodiments, the information of the first invoker includes one or more of: an application identifier of the first invoker, a user identifier UID of the first invoker, a developer signature of the first invoker, an account identifier of the first device where the first invoker is located, an identifier of the first device, an identifier of the communication system where the first invoker is located; the information of the first instance includes: a process identifier first PID of the first instance, a user identifier first UID of the first instance; the method further includes: when the second device creates the first instance, the second device assigns the first PID or the first UID to the first instance.

[0021] With reference to the first aspect, in some embodiments, the information of the first instance further includes one or more of: an application identifier of the invoker, a user identifier UID of the invoker, a developer signature of the invoker, an account identifier of the second device where the invoker is located, an identifier of the second device, an identifier of the communication system where the first instance is located.

[0022] With reference to the first aspect, in some embodiments, the method can further include: the first request further carries an identifier of the first device and an identifier of the second device.

[0023] With reference to the first aspect, in some embodiments, after the second device runs the first instance, the method further includes: the second device generates a first result; the second device returns the first result to the first device; the first device processes the first result by running the first invoker.

[0024] With reference to the first aspect, in some embodiments, before the second device runs the first instance, the method further includes: the second device confirms that the first invoker has the permission to access the first instance.

[0025] With reference to the first aspect, in some embodiments, before the second device runs the first instance, the method further includes: the second device confirms that the first invoker has the permission to request the invoker to provide the first service.

[0026] With reference to the first aspect, in some embodiments, before the first device sends the first request to the second device, the method further includes: the first device confirming that the first invoker has the permission to access the callee.

[0027] With reference to the first aspect, in some embodiments, the first device, the second device and the third device are the same device.

[0028] With reference to the first aspect, in some embodiments, the second device stores a mapping relationship between the first sandbox and the first invoker; and the second device stores a mapping relationship between the second sandbox and the second invoker.

[0029] The second aspect, the embodiments of the present application provide a method for access control, the method is applied to a second device, the second device is located in a communication system, the communication system includes a first device, a second device and a third device, wherein the first device installs a first invoker, the second device installs a callee, and the third device installs a second invoker; the first invoker, the callee and the second invoker are application programs or function components, the application program is a program entity for realizing multiple functions, and the function component is a program entity for realizing a single function.

[0030] The method includes: the second device receiving a first request sent by the first device, the first request carrying: the first invoker, the callee, and the indication information of a first service; in response to the first request, the second device running a first instance in a first sandbox, the first instance being an instance of the callee, and the first instance being used to provide the first service for the first invoker; the second device receiving a second request sent by the third device, the second request carrying: the second invoker, the callee, and the indication information of a second service; in response to the second request, the second device running a second instance in a second sandbox, the second instance being an instance of the callee, and the second instance being used to provide the second service for the second invoker, the second sandbox being different from the first sandbox.

[0031] The callee provides services for different invokers in different sandboxes, for example, the callee on the second device can run a first instance in a first sandbox to provide a first service for a first invoker on the first device, and the callee on the second device can run a second instance in a second sandbox to provide a second service for a second invoker on the third device, the data between different sandboxes is kept isolated, and the risk of misuse, confusion, misuse or leakage of data of each invoker can be more effectively reduced, and the data security is ensured.

[0032] With reference to the second aspect, in some embodiments, the method further includes: receiving, by the second device, a third request sent by the first device, the third request carrying: the first invoker, the callee, and indication information of a third service; and in response to the third request, running, by the second device, the first instance in the first sandbox, the first instance further configured to provide the third service for the first invoker, or running, by the second device, a third instance in the first sandbox, the third instance configured to provide the third service for the first invoker.

[0033] With reference to the second aspect, in some embodiments, the method further includes: receiving, by the second device, a fourth request sent by the first device, the fourth request carrying: the third invoker, the callee, and indication information of a fourth service, wherein the third invoker is installed in the first device, and the third invoker is an application program (APP) or a functional component; and in response to the fourth request, running, by the second device, the first instance in the first sandbox, the first instance further configured to provide the fourth service for the third invoker, or running, by the second device, a third instance in the first sandbox, the third instance configured to provide the fourth service for the third invoker.

[0034] With reference to the second aspect, in some embodiments, the method further includes: receiving, by the second device, a fifth request sent by the fourth device, the fifth request carrying: the first invoker, the callee, and indication information of a fifth service, wherein the first invoker is installed in the fourth device; and in response to the fifth request, running, by the second device, the first instance in the first sandbox, the first instance further configured to provide the fifth service for the first invoker of the fourth device, or running, by the second device, a third instance in the first sandbox, the third instance configured to provide the fourth service for the third invoker.

[0035] With reference to the second aspect, in some embodiments, the first invoker and the second invoker are the same.

[0036] With reference to the second aspect, in some embodiments, the first device and the third device are the same device.

[0037] With reference to the second aspect, in some embodiments, before the second device runs the first instance, the method further includes: detecting, by the second device, whether the first sandbox exists, and if not, creating, by the second device, the first sandbox; and before the second device runs the second instance, the method further includes: detecting, by the second device, whether the second sandbox exists, and if not, creating, by the second device, the second sandbox.

[0038] With reference to the second aspect, in some embodiments, the second device runs the first instance in the first sandbox, including: the second device creating the first instance and running the first instance in the first sandbox.

[0039] The second device runs the second instance in the second sandbox, including: the second device creating the second instance and running the second instance in the second sandbox.

[0040] With reference to the second aspect, in some embodiments, after the second device creates the first instance, the second device stores a first invocation relationship, the first invocation relationship including: information of the first invoker, information of the first instance, and an identifier of the first invocation relationship; after the second device creates the second instance, the second device stores a second invocation relationship, the second invocation relationship including: information of the second invoker, information of the second instance, and an identifier of the second invocation relationship.

[0041] With reference to the second aspect, in some embodiments, the information of the first invoker includes one or more of: an application identifier of the first invoker, a user identifier UID of the first invoker, a developer signature of the first invoker, an account identifier of the first invoker on the first device, an identifier of the first device, and an identifier of the communication system in which the first invoker is located; the information of the first instance includes: a process identifier first PID of the first instance and a user identifier first UID of the first instance; the method further includes: when the second device creates the first instance, the second device assigns the first PID or the first UID to the first instance.

[0042] With reference to the second aspect, in some embodiments, the information of the first instance further includes one or more of: an application identifier of the invoker, a user identifier UID of the invoker, a developer signature of the invoker, an account identifier of the invoker on the second device, an identifier of the second device, and an identifier of the communication system in which the first instance is located.

[0043] With reference to the second aspect, in some embodiments, the first request further carries an identifier of the first device and an identifier of the second device.

[0044] With reference to the second aspect, in some embodiments, after the second device runs the first instance, the method further includes: the second device generating a first result; and the second device returning the first result to the first device, the first result being used by the first device to run the first invoker process.

[0045] With reference to the second aspect, in some embodiments, before the second device runs the first instance, the method further includes: the second device confirming that the first invoker has the permission to access the first instance.

[0046] With reference to the second aspect, in some embodiments, before the second device runs the first instance, the method further includes: the second device confirming that the first invoker has the permission to request the callee to provide the first service.

[0047] With reference to the second aspect, in some embodiments, the first device, the second device and the third device are the same device.

[0048] With reference to the second aspect, in some embodiments, the second device stores the mapping relationship between the first sandbox and the first invoker and the mapping relationship between the second sandbox and the second invoker.

[0049] In a third aspect, an embodiment of the present application provides an electronic device, which can include: a communication device, a memory, and a processor coupled to the memory, a plurality of application programs, and one or more programs. The memory stores computer executable instructions, and the processor executes the instructions to enable the electronic device to implement any function of the second device as described in the second aspect.

[0050] In a fourth aspect, an embodiment of the present application provides a communication system, which can include the first device, the second device, the third device, etc. described in the foregoing aspects. It can be understood that, based on the same inventive idea, each step performed by the first device, the second device, and the third device in the communication system of the fourth aspect can refer to the steps performed by the first device, the second device, and the third device when implementing the corresponding functions in the method of the first aspect, or each step performed by the second device can refer to the steps performed by the second device when implementing the corresponding functions in the method of the second aspect, which will not be described herein again.

[0051] In a fifth aspect, an embodiment of the present application provides a computer storage medium, which stores a computer program including executable instructions, and the executable instructions, when executed by a processor, enable the processor to perform operations corresponding to the method provided in the second aspect.

[0052] In a sixth aspect, an embodiment of the present application provides a computer program product, which, when running on an electronic device, enables the electronic device to perform any possible implementation manner of the second aspect.

[0053] In a seventh aspect, the embodiments of the present application provide a chip system, which can be applied to an electronic device. The chip includes one or more processors, and the processor is configured to invoke computer instructions to enable the electronic device to implement any possible implementation manner of the second aspect.

[0054] By implementing the above method provided in the present application, one same invoker can enable multiple sandboxes, and use different instances to provide services for different invokers. Due to the natural isolation property between the sandboxes, different sandboxes cannot access data of each other, so that a system-level data security mechanism can be provided, and the problems of misuse, abuse and leakage of data of each invoker are avoided, and the data security is ensured. BRIEF DESCRIPTION OF DRAWINGS

[0055] Figure 1 A schematic diagram of a communication system provided by the embodiments of the present application;

[0056] Figure 2 A schematic diagram of an application scenario provided by the embodiments of the present application;

[0057] Figure 3 A schematic diagram of a hardware structure of an electronic device provided by the embodiments of the present application;

[0058] Figure 4 A schematic diagram of a business scenario provided by the embodiments of the present application;

[0059] Figure 5 A schematic diagram of a prior art solution;

[0060] Figure 6 A schematic diagram of a software architecture provided by the embodiments of the present application;

[0061] Figure 7 A schematic diagram of a model of access control provided by the embodiments of the present application;

[0062] Figure 8 A flowchart of a method of access control provided by the embodiments of the present application;

[0063] Figure 9 A flowchart of another method of access control provided by the embodiments of the present application;

[0064] Figures 10(A) to 10(C) Schematic diagrams of three different application data isolation methods provided by the embodiments of the present application. DETAILED DESCRIPTION

[0065] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B; the "and / or" in the text only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which means that there are three cases of A alone, A and B together, and B alone.

[0066] In the following, the terms "first" and "second" are only used for description purposes, and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features, and in addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0067] In the following embodiments of the present application, the term "user interface (UI)" is a medium interface for interaction and information exchange between an application or an operating system and a user, which 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, extensible markup language (XML), etc. The interface source code is parsed, rendered, and finally presented as content that can be recognized by the user on the electronic device. The commonly used form of user interface is graphic user interface (GUI), which refers to a user interface related to computer operation displayed in a graphical manner. It can be a visual interface element such as text, icon, button, menu, tab, text box, dialog box, status bar, navigation bar, Widget, etc. displayed in the display screen of the electronic device.

[0068] First, the communication system provided by the embodiments of the present application is introduced.

[0069] Figure 1 A communication system 10 provided by the embodiments of the present application is shown, which can also be referred to as Distributed system 10 .

[0070] The distributed system 10 can include a plurality of intelligent terminal devices, and the plurality of terminal devices are connected by a communication connection 109. For example, as Figure 1As shown in FIG. 1, the terminal devices can be a smartphone 101, a notebook computer 102, a desktop computer 103, a tablet computer 104, a smart speaker 105, a smart watch 106, a smart bracelet 107, a headset 108, or other types of electronic devices, which can also include a desktop computer, a laptop computer, a handheld computer, an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a smart screen, a car machine, a game machine, other smart wearable devices, and the like, and can also include an internet of things (IOT) device or a smart home device such as a smart water heater, a smart lamp, a smart air conditioner, and the like. The present application does not make any limitation in this regard. In the present embodiment, the terminal device can also be referred to simply as a terminal, and the terminal device is generally a smart electronic device that can provide a user interface, can interact with a user, and can provide a service function for the user.

[0071] When the plurality of electronic devices in the distributed system 10 are all devices deployed in a home, the distributed system 10 can also be referred to as a home distributed system.

[0072] The terminal devices in the distributed system 10 can be equipped with a system, a system, a system, HarmonyOS (HOS) or other types of operating systems, and the operating systems of the terminal devices in the distributed system 10 can be the same or different, and the present application does not make any limitation in this regard. In some embodiments, each terminal in the distributed system 10 is equipped with a system, and the distributed system 10 can be referred to as a super virtual device, which can also be referred to as a super terminal, which refers to integrating the capabilities of multiple terminals through distributed technology, storing in a virtual hardware resource pool, and providing services to the outside by uniformly managing, scheduling and integrating terminal capabilities to achieve fast connection, capability assistance and resource sharing between different terminals.

[0073] In the distributed system 10, a communication connection 109 is established between each terminal, which can be a far-field communication connection, such as each terminal logging into the same account to implement connection and communication through the Internet. The plurality of electronic devices in the distributed system 10 can also log into different accounts, but are connected through binding. For example, the electronic device 100 and the electronic device 200 can log into different accounts, and the electronic device 100 binds the electronic device 200 and itself in the device management application, and then connects through the device management application. In the following embodiments of the present application, the electronic device 100 can be any electronic device in the distributed system 10, and the electronic device 200 can also be any electronic device in the distributed system 10. For example, the electronic device 100 is a smart phone, and the electronic device 200 is a smart screen.

[0074] In the distributed system 10, the communication connection 109 can also be a near-field communication connection, such as a wired connection, such as a universal serial bus (USB) connection, or a wireless connection, such as a Bluetooth (BT) connection, a wireless fidelity (Wi-Fi) connection, etc., to realize communication between each terminal without an account or with different accounts. The type of communication connection is not limited in the embodiments of the present application. The terminal device can be configured with a Bluetooth (BT) module and / or a wireless local area network (WLAN) module. The Bluetooth module can provide a solution including one or more Bluetooth communications of classic Bluetooth (Bluetooth 2.1) or Bluetooth low energy (BLE), and the WLAN module can provide a solution including one or more WLAN communications of wireless fidelity peer-to-peer (Wi-Fi P2P), wireless fidelity local area networks (Wi-Fi LAN), or wireless fidelity software access point (Wi-Fi softAP). In some embodiments, Wi-Fi P2P refers to allowing devices in a wireless network to be connected to each other in a point-to-point form without passing through a wireless router, and in The system can also be referred to as wireless fidelity direct (Wi-Fi direct). The devices establishing a Wi-Fi P2P connection can directly exchange data through Wi-Fi (must be in the same frequency band) without connecting to a network or a hotspot, to realize point-to-point communication, such as transmitting files, pictures, videos, and other data. Compared with Bluetooth, Wi-Fi P2P has the advantages of faster search speed and transmission speed, and longer transmission distance. The terminals can transmit and interact data through the communication connection 109.

[0075] In addition, the plurality of electronic devices in the distributed system 10 can also be connected and communicated in combination with any of the above-described manners, and embodiments of the present application do not limit this.

[0076] In embodiments of the present application, each device in the distributed system 10 can install a traditional APP, such as a traditional camera application, a gallery application, a settings application, and the like. In subsequent embodiments, the traditional APP can be referred to as APP.

[0077] In addition, the distributed system 10 provided by embodiments of the present application can install a distributed application. The distributed application can be a system application or a third-party application, which is not limited here.

[0078] Unlike traditional application programs containing multiple capabilities, a distributed application supports deployment in units of single capabilities. An APP refers to a computer program that can implement one or more functions, can be independently run, usually has a visual user interface, and can interact with a user. A distributed application includes one or more functional components.

[0079] Functional components A functional component is the smallest capability unit that can be independently run in an electronic device, and is a concept of abstract encapsulation of a single capability. A traditional APP groups multiple functions together, while a functional component exists independently as a service-based basic capability of each function. That is, a functional component is a program entity that implements a single function.

[0080] Each functional component can be independently downloaded, installed, and run. Multiple functional components constituting a same distributed application can be deployed in a same electronic device in the distributed system 10, or can be deployed in different electronic devices. A distributed application can implement encapsulation of remote virtualization, remote calling, meta-capability management, cross-platform compatibility, security, and other functional modules. A distributed application can call computing capabilities of other devices that the present device does not have, and has the capability of splitting computing work of the present device to multiple devices to cooperatively complete the work.

[0081] The distributed system 10 can endow the functional components with more flexible orchestrating, migrating, etc. The distributed system 10 can make the functional components work together to complete a task by orchestrating appropriate functional components.

[0082] It can be understood that the functional component is only a term used in the embodiment, and the meaning represented by the functional component has been described in the embodiment, and the name of the functional component does not constitute any limitation on the embodiment. In addition, in some other embodiments of the application, the functional component can also be referred to as a system component, a system service, a business function, a meta ability / atomic ability (Ability), or other terms. Subsequent embodiments of the application are uniformly described as "functional component".

[0083] For example, a system, The functional components in the system can include the following two categories:

[0084] (1) Particle ability (PA).

[0085] The PA is a functional component without UI, which can be described as an atomic service or an atomic functional module / unit, is a program entity that can implement a single function, and is a program fragment that can be independently executed. The PA can provide support for the FA, such as providing computing capability as a background service or providing data access capability as a data warehouse. For example, a beauty function, a positioning function, an audio / video codec function, etc. can be encapsulated as a PA. In some embodiments, the particle ability (PA) can also be referred to as an atomic ability (AA).

[0086] The PA has the characteristics of multi-end deployment and distributed execution. The PA only has a dependency relationship with a system service, and does not have a dependency relationship with other PAs.

[0087] The PA can actually encapsulate remote virtualization, remote calling, PA management, cross-platform compatibility, security, etc. The PA exposes the enabled and awakened services across devices to developers, so that other devices can call the computing capability of the device and work together with other devices to complete the computing work. The PA supports Service Ability and Data Ability. The Service Ability is used to provide the ability of running a background task. The Data Ability is used to provide a unified data access abstraction to the outside.

[0088] In the embodiments of the application, the PA can be called by other APPs or FAs or PAs, and the PA can call other PAs or FAs or APPs to implement more complex functions.

[0089] (2) Feature ability (FA).

[0090] FA is a functional component containing one or several groups of UI, which can provide the ability to interact with the user. For example, the navigation interface in the map application, the video call interface in the instant messaging application, etc. can be implemented as FA.

[0091] In some embodiments, the FA can be developed based on the MVVM (model-view-view-model) mode, which separates the view UI and the business logic. The business logic code and the view UI code are deployed separately, and the view UI code can be integrated into other APPs. During the running process of the view UI code, it can communicate with the business logic code to obtain the data required for UI display.

[0092] FA supports the ability of page templates, such as Empty Ability, Login Ability, Setting Ability, etc. FA can use a script language (java script, JS) to provide a declarative development mode, use a class HTML and a cascading style sheet (CSS) declarative programming language as a development language for page layout and page style, and support the JS language of ECMAScript specification to provide page business logic.

[0093] FA can have the ability of installation-free, independent running, cross-device UI migration, cross-device binary migration, etc. FA also has the characteristics of multi-end deployment and distributed execution.

[0094] In the embodiments of the present application, the FA can be called by other APPs or FAs or PAs, and the FA can also call other PAs or FAs or APPs to realize more and more complex functions.

[0095] Similarly, the functional component PA / FA has the characteristics of multi-end deployment and distributed execution, that is, a distributed application can contain multiple PA / FA, and multiple PA / FA can be deployed in the same or different terminal devices. Each terminal device in the distributed system 10 can be installed with APP / PA / FA, and the terminal devices in the distributed system 10 can synchronize the PA / FA information of other terminal devices for easy calling. For example, the PA / FA deployed in a terminal device can be called by the application deployed in the terminal device, or by the application deployed in other terminal devices in the distributed system 10.

[0096] It can be understood that "FA" and "PA" are only a word used in the embodiment, and in some other embodiments of the application, it can also be referred to as other names. For example, "PA" and "FA" can also be referred to as other names such as atomic capability, atomic application, meta capability, atomic function module / unit, etc. Similarly, "PA" can also be referred to as other names such as meta service, atomic service, atomic service, etc. in some other embodiments, and "FA" can also be referred to as other names such as characteristic capability, meta program, etc. in some other embodiments.

[0097] The plurality of functional components constituting a distributed application can be developed or provided by the same developer, or can be developed or provided by a plurality of developers, which is not limited herein. The developers jointly develop the functional components, which can improve the development efficiency of the distributed application.

[0098] In the embodiments of the application, the functional components can provide standardized calling interfaces to the outside for being called by the calling party. The calling party refers to the initiator of the calling request, and the called party refers to the target object of the calling request. An ordinary APP can call the functional components, and the called functional components can further call other functional components. This multi-level calling can be called chain calling.

[0099] In the embodiments of the application, in a calling relationship, the party initiating the calling function can be called a calling party or a caller, and the party providing resources called by the calling party can be called a called party or a callee. The calling party or the called party can be an APP, an FA or a PA. The initial initiator of the entire calling chain can be called a first caller, and the first caller can be an APP or an FA, for example. For example, the calling chain is: APP1 calls PA1, PA1 calls PA2, and PA2 calls FA1, and APP1 is the first caller. For another example, the calling chain is: FA1 calls PA1, and PA1 calls PA2, and FA1 is the first caller.

[0100] In some embodiments of the application, the calling party can also be called a subject application, and the called party can also be called an object application.

[0101] In the calling chain, each calling party and the called party can be deployed in the same electronic device or in different electronic devices.

[0102] The device where the calling party is located can be called a subject device, and the device where the called party is located can be called an object device.

[0103] After establishing communication connections among the devices in distributed system 10, each device will synchronize functional component information and APP information from other devices in the distributed system. Specifically, each device can synchronize the identifiers of its installed functional components and / or APPs, as well as its own device information (such as device identifier), to distributed system 10, making them visible to other devices to facilitate subsequent mutual calls between devices in distributed system 10. The callers that can invoke each functional component or APP, and which other functional components or APPs can be invoked—that is, the calling permissions and / or called permissions—can be pre-set and recorded on each electronic device and synchronized in distributed system 10.

[0104] To facilitate understanding, a simple example is provided here, based on the foregoing description.

[0105] refer to Figure 2 Distributed system 10 includes electronic device A and electronic device B. Electronic device A deploys application A, functional component A, and functional component B, while electronic device B deploys application B, functional component C, and functional component D. Each electronic device in distributed system 10 can access and invoke functional components on other electronic devices. For example, application A can implement corresponding functions by invoking functional components A, B, and C on electronic device B, and application B can implement corresponding functions by invoking functional components C and D. Besides applications invoking functional components, functional components can also invoke each other; for example, functional component B deployed on electronic device A can invoke functional component D deployed on electronic device B.

[0106] It should be noted that, Figure 1 , Figure 2 The scenarios illustrated are for illustrative purposes only and do not constitute a limitation on the embodiments of this application. In actual business scenarios, the distributed system 10 may include more or fewer terminal devices, and each terminal device may deploy more or fewer distributed applications and / or PAs / FAs. Each distributed application may include more or fewer PAs / FAs, and there are no restrictions on the calling relationships between the various APPs / PAs / FAs.

[0107] The structure of the electronic device provided in the embodiments of this application is described exemplarily below.

[0108] The electronic device provided in this application embodiment can be... Figure 1 Any of the electronic devices described in the distributed system 10 shown can also be electronic device 100 or electronic device 200 or other electronic devices in subsequent embodiments of this application, and there is no limitation here. Electronic device 100 is used as an example for illustration here.

[0109] In the embodiments of the present application, the electronic device 100 can include, but is not limited to, a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, and a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device. The embodiments of the present application do not make any limitation on the specific type of the electronic device 100.

[0110] Figure 3 The hardware structure schematic diagram of the electronic device 100 provided in the embodiments of the present application is shown in FIG. 1.

[0111] The electronic device 100 can 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 loudspeaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, a sensor module 180, a key 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 can include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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.

[0112] It can be understood that the structure shown in the embodiments of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 can include more or fewer components than shown, or combine certain components, or split certain components, or different arrangement of components. The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0113] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units can be independent devices or integrated in one or more processors.

[0114] The controller can generate operation control signals according to the instruction operation code and the timing signal, and complete the control of fetching and executing instructions.

[0115] The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory can save instructions or data that have just been used or are used repeatedly by the processor 110. If the processor 110 needs to use the instructions or data again, it can directly call from the memory. This avoids repeated access and reduces the waiting time of the processor 110, thereby improving the efficiency of the system.

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

[0117] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 can contain multiple sets of I2C bus. The processor 110 can be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces respectively. For example, the processor 110 can be coupled to the touch sensor 180K through an I2C interface, so that the processor 110 and the touch sensor 180K communicate through the I2C bus interface, and the touch function of the electronic device 100 is realized.

[0118] The I2S interface can be used for audio communication. In some embodiments, the processor 110 can contain multiple sets of I2S bus. The processor 110 can be coupled to the audio module 170 through the I2S bus, and communication between the processor 110 and the audio module 170 is realized. In some embodiments, the audio module 170 can deliver audio signals to the wireless communication module 160 through the I2S interface, and the function of answering a phone through a Bluetooth headset is realized.

[0119] The PCM interface can also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled through the PCM bus interface. In some embodiments, the audio module 170 can also deliver audio signals to the wireless communication module 160 through the PCM interface, and the function of answering a phone through a Bluetooth headset is realized. Both the I2S interface and the PCM interface can be used for audio communication.

[0120] The UART interface is a universal serial data bus, which is used for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is usually used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface, and the Bluetooth function is realized. In some embodiments, the audio module 170 can deliver audio signals to the wireless communication module 160 through the UART interface, and the function of playing music through a Bluetooth headset is realized.

[0121] The MIPI interface can be used to connect the processor 110 and the display screen 194, the camera 193 and other peripheral devices. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), and the like. In some embodiments, the processor 110 and the camera 193 communicate through the CSI interface to implement the photographing function of the electronic device 100. The processor 110 and the display screen 194 communicate through the DSI interface to implement the display function of the electronic device 100.

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

[0123] The USB interface 130 is an interface that conforms to the USB standard specification, and can be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 can be used to connect a charger to charge the electronic device 100, or to transmit data between the electronic device 100 and a peripheral device. It can also be used to connect a headset to play audio through the headset. The interface can also be used to connect other electronic devices, such as AR devices and the like.

[0124] It can be understood that the interface connection relationship between the modules shown in the embodiments of the present application is only illustrative and does not constitute a structural limitation of the electronic device 100. In other embodiments of the present application, the electronic device 100 can also use different interface connection methods or combinations of multiple interface connection methods in the above embodiments.

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

[0126] The power management module 141 is configured to connect the battery 142 and the charging management module 140 to the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 can also be configured to monitor parameters such as battery capacity, battery cycle count, battery health status (leakage, impedance), and the like. In some embodiments, the power management module 141 can also be disposed in the processor 110. In some embodiments, the power management module 141 and the charging management module 140 can also be disposed in the same device.

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

[0128] The antenna 1 and the antenna 2 are configured to transmit and receive electromagnetic wave signals. Each antenna in the electronic device 100 can be configured to cover a single or multiple communication frequency bands. Different antennas can also be multiplexed to improve the utilization of the antennas. For example, the antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some embodiments, the antennas can be used in combination with a tuning switch.

[0129] The mobile communication module 150 can provide a solution for wireless communication including 2G / 3G / 4G / 5G and the like applied to the electronic device 100. The mobile communication module 150 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), and the like. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and perform filtering, amplification, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can also amplify signals modulated by the modem processor, and radiate the amplified signals as electromagnetic waves through the antenna 1. In some embodiments, at least part of the function modules of the mobile communication module 150 can be disposed in the processor 110. In some embodiments, at least part of the function modules of the mobile communication module 150 and at least part of the modules of the processor 110 can be disposed in the same device.

[0130] The modem processor can include a modulator and a demodulator. The modulator is configured to modulate a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is configured to demodulate a received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. The low-frequency baseband signal processed by the baseband processor is transmitted to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a microphone 170B, etc.), or displays an image or a video through the display 194. In some embodiments, the modem processor can be a separate device. In other embodiments, the modem processor can be independent of the processor 110 and disposed in the same device as the mobile communication module 150 or other functional modules.

[0131] The wireless communication module 160 can provide a wireless communication solution including wireless local area networks (WLAN) (e.g., wireless fidelity (Wi-Fi) network), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc. The wireless communication module 160 can be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signal, and transmits the processed signal to the processor 110. The wireless communication module 160 can also receive a signal to be transmitted from the processor 110, perform frequency modulation, amplification, and convert it into electromagnetic wave radiation via the antenna 2.

[0132] In some embodiments, the antenna 1 and the mobile communication module 150 of the electronic device 100 are coupled, and the antenna 2 and the wireless communication module 160 are coupled, so that the electronic device 100 can communicate with a network and other devices through wireless communication technology. The wireless communication technology can 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 technology, etc. The GNSS can include a global positioning system (GPS), a global navigation satellite system (GLONASS), a beidu navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and / or a satellite based augmentation systems (SBAS).

[0133] The electronic device 100 implements a display function through a GPU, a display screen 194, and an application processor, etc. The GPU is a microprocessor for image processing, which is connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 can include one or more GPUs, which execute program instructions to generate or change display information.

[0134] The display screen 194 is configured to display images, videos, and the like. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flex light-emitting diode (FLED), a Miniled, a MicroLed, a Micro-oLed, a quantum dot light emitting diodes (QLED), or the like. In some embodiments, the electronic device 100 can include one or N display screens 194, where N is a positive integer greater than 1.

[0135] The electronic device 100 can implement the photographing function through the ISP, the camera 193, the video codec, the GPU, the display screen 194, and the application processor.

[0136] The ISP is configured to process the data fed back by the camera 193. For example, when taking a photo, the shutter is opened, the light is transmitted to the camera photosensitive element through the lens, the light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing to convert it into an image visible to the naked eye. The ISP can also optimize the noise, brightness, and skin color of the image. The ISP can also optimize the exposure, color temperature, and other parameters of the shooting scene. In some embodiments, the ISP can be disposed in the camera 193.

[0137] The camera 193 is configured to capture still images or videos. An object generates an optical image through a lens and projects it onto a photosensitive element. 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 transmitted to the ISP to convert it into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, the electronic device 100 can include one or N cameras 193, where N is a positive integer greater than 1.

[0138] The digital signal processor is used to process digital signals, in addition to being able to process digital image signals, it can also process other digital signals. For example, when the electronic device 100 is in frequency point selection, the digital signal processor is used to perform Fourier transform on the frequency point energy, etc.

[0139] The video codec is used to compress or decompress digital video. The electronic device 100 can support one or more video codecs. In this way, the electronic device 100 can play or record videos in multiple encoding formats, such as: moving picture experts group (MPEG) 1, MPEG 2, MPEG 3, MPEG 4, etc.

[0140] The NPU is a neural-network (NN) calculation processor, which can quickly process input information by drawing on the structure of a biological neural network, such as drawing on the transmission mode between human brain neurons, and can also constantly self-learn. Through the NPU, the electronic device 100 can realize intelligent cognitive applications, such as: image recognition, face recognition, voice recognition, text understanding, etc.

[0141] The internal memory 121 can include one or more random access memories (RAMs) and one or more non-volatile memories (NVMs).

[0142] The random access memory has the characteristics of fast read / write speed and volatility. Volatility means that once the power is off, the data stored in the RAM will disappear. Generally, the static power consumption of the random access memory is very low, and the running power consumption is relatively large.

[0143] The non-volatile memory has the characteristics of non-volatility and stable data storage. Non-volatility means that after power off, the data stored will not disappear and can be saved for a long time.

[0144] The random access memory can include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM, such as the fifth generation of DDR SDRAM commonly referred to as DDR5 SDRAM), and the like. The non-volatile memory can include a magnetic disk storage, a flash memory, and the like.

[0145] The disk storage is a storage with a disk as a storage medium, and has the characteristics of large storage capacity, high data transfer rate, long-term storage of stored data, and the like.

[0146] The flash memory can include NOR FLASH, NAND FLASH, 3D NAND FLASH, and the like according to the operation principle, and can include single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), and the like according to the storage unit potential order, and can include universal flash storage (UFS), embedded multi media Card (eMMC), and the like according to the storage specification.

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

[0148] The non-volatile memory can also store executable programs and data of users and application programs, and the like, and can be loaded in advance into the random access memory for direct reading and writing by the processor 110.

[0149] The external memory interface 120 can be used to connect an external nonvolatile memory, to extend the storage capacity of the electronic device 100. The external nonvolatile memory communicates with the processor 110 through the external memory interface 120, to implement a data storage function. For example, files such as music, video, and the like are saved in the external nonvolatile memory.

[0150] The electronic device 100 can implement an audio function through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor, and the like. For example, music playing, recording, and the like.

[0151] The audio module 170 is used to convert digital audio information into an analog audio signal output, and is also used to convert an analog audio input into a digital audio signal. The audio module 170 can also be used to encode and decode an audio signal. In some embodiments, the audio module 170 can be disposed in the processor 110, or part of the function modules of the audio module 170 can be disposed in the processor 110.

[0152] The speaker 170A, also called a "loudspeaker", is used to convert an audio electrical signal into a sound signal. The electronic device 100 can listen to music or listen to a hands-free call through the speaker 170A.

[0153] The receiver 170B, also called an "earpiece", is used to convert an audio electrical signal into a sound signal. When the electronic device 100 answers a call or a voice message, the receiver 170B can be held close to the ear of a person to listen to the voice.

[0154] The microphone 170C, also called a "microphone", "sound transducer", is used to convert a sound signal into an electrical signal. When making a call or sending a voice message, a user can speak into the microphone 170C through the mouth, to input a sound signal into the microphone 170C. The electronic device 100 can be provided with at least one microphone 170C. In other embodiments, the electronic device 100 can be provided with two microphones 170C, in addition to collecting a sound signal, to implement a noise reduction function. In other embodiments, the electronic device 100 can be provided with three, four or more microphones 170C, to collect a sound signal, to implement noise reduction, and to identify a sound source, to implement a directional recording function, and the like.

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

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

[0157] There are many types of pressure sensors, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, etc. The capacitive pressure sensor can include at least two parallel plates with conductive material. When a force is applied to the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the force according to the change in capacitance. When a touch operation is applied to the display screen 194, the electronic device 100 detects the intensity of the touch operation according to the pressure sensor 180A. The electronic device 100 can also calculate the position of the touch according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation instructions. For example, when a touch operation with an intensity less than a first pressure threshold is applied to a short message application icon, an instruction to view a short message is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the short message application icon, an instruction to create a new short message is executed.

[0158] The gyroscope sensor 180B can be used to determine the motion attitude of the electronic device 100. In some embodiments, the angular velocity of the electronic device 100 around three axes (i.e., the x, y, and z axes) can be determined by the gyroscope sensor 180B. The gyroscope sensor 180B can be used for anti-shake photography. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle of the shaking of the electronic device 100, and calculates the distance that the lens module needs to compensate according to the angle, so that the lens counteracts the shaking of the electronic device 100 by reverse movement, thereby achieving anti-shake. The gyroscope sensor 180B can also be used for navigation and motion sensing game scenarios.

[0159] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates the altitude, assists positioning and navigation by using the air pressure value measured by the barometric pressure sensor 180C.

[0160] The magnetic sensor 180D includes a Hall sensor. The electronic device 100 can detect opening and closing of a flip cover with the magnetic sensor 180D. In some embodiments, when the electronic device 100 is a flip phone, the electronic device 100 can detect opening and closing of the flip according to the magnetic sensor 180D. In turn, according to the detected opening and closing state of the cover or the flip, a feature such as automatic unlocking of the flip is set.

[0161] The acceleration sensor 180E can detect the magnitude of acceleration of the electronic device 100 in various directions (typically, three axes). The magnitude and direction of gravity can be detected when the electronic device 100 is stationary. It can also be used to identify the electronic device posture, applied to landscape / portrait switching, pedometer, etc.

[0162] The distance sensor 180F is used to measure distance. The electronic device 100 can measure distance by infrared or laser. In some embodiments, when a scene is photographed, the electronic device 100 can measure distance with the distance sensor 180F to achieve fast focusing.

[0163] The proximity light sensor 180G can include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode can be an infrared light emitting diode. The electronic device 100 emits infrared light outwardly through the light emitting diode. The electronic device 100 detects infrared reflected light from nearby objects using the photodiode. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 100. When insufficient reflected light is detected, the electronic device 100 can determine that there is no object near the electronic device 100. The electronic device 100 can detect that the user holds the electronic device 100 close to the ear for a call with the proximity light sensor 180G, so as to automatically turn off the screen to achieve power saving. The proximity light sensor 180G can also be used for automatic unlocking and locking of the cover mode and pocket mode.

[0164] The ambient light sensor 180L is used to sense ambient light brightness. The electronic device 100 can adaptively adjust the display screen 194 brightness according to the sensed ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the electronic device 100 is in the pocket to prevent accidental touch.

[0165] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint unlocking, access application lock, fingerprint photographing, fingerprint answering incoming calls, etc.

[0166] The temperature sensor 180J is configured to detect temperature. In some embodiments, the electronic device 100 performs temperature handling strategies based on the temperature detected by the temperature sensor 180J. For example, when the temperature reported by the temperature sensor 180J exceeds a threshold, the electronic device 100 reduces the performance of a processor located near the temperature sensor 180J to reduce power consumption and implement thermal protection. In another example, when the temperature is lower than another threshold, the electronic device 100 heats the battery 142 to avoid abnormal shutdown of the electronic device 100 caused by low temperature. In yet another example, when the temperature is lower than yet another threshold, the electronic device 100 boosts the output voltage of the battery 142 to avoid abnormal shutdown caused by low temperature.

[0167] The touch sensor 180K is also referred to as a "touch device". The touch sensor 180K can be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also referred to as a "touch panel". The touch sensor 180K is configured to detect a touch operation applied thereto or in the vicinity thereof. The touch sensor 180K can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In another example, the touch sensor 180K can also be disposed on the surface of the electronic device 100, which is different from the position of the display screen 194.

[0168] The bone conduction sensor 180M can obtain a vibration signal. In some embodiments, the bone conduction sensor 180M can obtain a vibration signal of a human body sound vibration bone block. The bone conduction sensor 180M can also contact the human body pulse to receive a blood pressure pulsation signal. In some embodiments, the bone conduction sensor 180M can also be disposed in a headset to form a bone conduction headset. The audio module 170 can analyze a voice signal based on the vibration signal of the sound vibration bone block obtained by the bone conduction sensor 180M to implement a voice function. The application processor can analyze heart rate information based on the blood pressure pulsation signal obtained by the bone conduction sensor 180M to implement a heart rate detection function.

[0169] The keys 190 include a power key, a volume key, and the like. The keys 190 can be mechanical keys. Alternatively, the keys 190 can be touch keys. The electronic device 100 can receive a key input and generate a key signal input related to user settings and function control of the electronic device 100.

[0170] The motor 191 can generate a vibration prompt. The motor 191 can be used for incoming call vibration prompt, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, playing audio, etc.) can correspond to different vibration feedback effects. The motor 191 can also correspond to different vibration feedback effects for touch operations acting on different regions of the display screen 194. Different application scenarios (such as time reminders, received messages, alarms, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also be customized.

[0171] The indicator 192 can be an indicator light, which can be used to indicate the charging state, the power change, and can also be used to indicate messages, missed calls, notifications, etc.

[0172] The SIM card interface 195 is used to connect the SIM card. The SIM card can be inserted into or pulled out of the SIM card interface 195 to realize contact and separation with the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, and N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, etc. The same SIM card interface 195 can simultaneously insert multiple cards. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external storage cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as calling and data communication. In some embodiments, the electronic device 100 uses an eSIM, that is, an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0173] In combination with the description of the distributed system 10 above, reference is made to Figure 4 , Figure 4 An exemplary distributed remote teaching business scenario is shown.

[0174] As shown in Figure 4 , the distributed system includes smartphones, tablets, smart screens, and other electronic devices. Each device in the distributed system is connected to each other. The smartphones, tablets, and smart screens can be configured with different software operating systems (OS), for example, the smartphones and tablets can be configured with systems, and the smart screens can be configured with systems.

[0175] The smartphone is installed with an "online classroom" application. The "online classroom" is an application installed in an electronic device, which provides various functions required for teachers and students to have remote classes. The name of the "online classroom" is not limited in the embodiments of the present application. The "online classroom" can include the following functional components: a blackboard functional component, a whiteboard functional component, an audio / video codec functional component, and a network connection functional component. Among them, the blackboard functional component and the whiteboard functional component belong to the FA, and the audio / video codec functional component and the network connection functional component belong to the PA. The blackboard functional component provides the function of remotely explaining a course. The whiteboard functional component provides the function of remotely answering questions. The audio / video codec functional component provides the video and audio codec function. Among them, the blackboard functional component and the whiteboard functional component can also realize the video communication function by calling the video call functional component in the smartphone. The video call functional component belongs to the PA.

[0176] On the teacher side, when the teacher uses the "online classroom" on the smartphone, the blackboard functional component can be migrated or switched to the smart screen, so as to explain the course on the smart screen.

[0177] On the student side, when the student uses the "online classroom" on the smartphone, the whiteboard functional component can be migrated or switched to the tablet computer, so as to answer questions on the tablet computer.

[0178] Migrating or switching the functional component from one device A to another device B can include the following two kinds: 1, UI migration. When the view UI and the business logic of the FA are separated, the device A can run the business logic code, which can trigger the device B to run the code of the view UI, so that the user seems to have migrated the functional component from the device A to the device B. 2, overall migration. The overall migration refers to that the device B downloads and installs the functional component from the device A or from the network, and then runs the functional component and provides the corresponding function.

[0179] In the remote teaching business scenario, the "online classroom" is the calling party, and the whiteboard functional component in the tablet computer and the blackboard functional component in the smart screen are the called parties.

[0180] Figure 4 Another possible distributed video call business scenario is also shown.

[0181] As Figure 4 shown, the smartphone can also be installed with other distributed applications, such as an instant messaging application. The instant messaging application can provide video call, voice call and other communication functions. The instant messaging application can include the following functional components: a video call functional component, an audio / video codec functional component, and a network connection functional component.

[0182] When a user uses an instant messaging application on a smartphone, the user can migrate or switch a video call function component of the application to a smart screen or a tablet computer, so as to use a camera and a display screen of the smart screen or the tablet computer to perform a video call.

[0183] In the video call service scenario, the instant messaging application is a caller, and the video call function component is a callee.

[0184] It should be noted that the service scenario shown in Figure 4 is only used to assist in describing the technical solutions of the embodiments of the present application. In the actual service scenario, the distributed system shown in Figure 4 may include more terminal devices, and more or fewer function components can be deployed in each device, and each distributed application can include more or fewer function components.

[0185] Through the distributed system 10 shown in Figure 1 , Figure 2 and the distributed service scenario shown in Figure 4 , the software and hardware capabilities of different devices can be integrated to realize intelligent full-scene experience.

[0186] In the distributed system 10 shown in Figure 1 , Figure 2 and the distributed service scenario shown in Figure 4 , since the function components can be called across devices, in order to avoid confusion, misuse or malicious use of the memory data of each caller, to ensure that each function component can reasonably access device resources, and to protect the safe sharing of resources and data between devices in the distributed system, the present embodiment provides an access control method, which will be described in detail below.

[0187] Here, the resources shared between devices in the distributed system can include but are not limited to software resources, hardware resources, peripheral or accessory resources of the device, etc.

[0188] The data generated by the application program or the function component during its running process can include the following two types:

[0189] 1. Memory data.

[0190] When an electronic device starts or initiates an instance of an application program or a function component, corresponding memory data will be generated.

[0191] The memory data is the data in the RAM, which can be read at any time and disappears after power off.

[0192] An instance is an application program or a functional component in a running state. In the embodiments of the present application, an instance can refer to a process or a thread. A process is an execution activity of an application program or a functional component on a computer. A thread is a single sequential control flow in the execution of an application program or a functional component. One process can include multiple threads.

[0193] That is, as long as an application program or a functional component starts running, a corresponding instance is generated, and memory data is produced.

[0194] 2, application data.

[0195] Application data refers to the content written in the running process of an application program or a functional component, such as photos or videos obtained by a photo application, text edited by a user in a document application, and the like. Application data can also be referred to as file data.

[0196] Application data is data in the NVM, which can be stably stored in the NVM for a long time.

[0197] In a traditional single-machine scenario, an APP in an electronic device applies for access authorization of sensitive resources to a user in the form of an independent subject, and after the authorization is passed, the user is directly provided with various services.

[0198] Considering that application data in multiple APPs in an electronic device is stored in the NVM in a single-machine scenario, after the APP is authorized by a user, the authorized APP can have access permission to all data in the NVM, and after the APP is invaded, data in the NVM will be leaked. On this basis, the related technology proposes the concept of a sandbox.

[0199] A sandbox (Sandbox), also known as a sandbox, is a virtual system program with an independent running environment, that is, the virtual system has independent RAM and NVM, and allows an APP to run therein. Through the isolation of the sandbox, the APP in the sandbox can only access resources in the sandbox and cannot access other resources in the device, thereby ensuring the security and stability of the device.

[0200] Reference Figure 5 , Figure 5 An exemplary implementation manner of a traditional APP in a single-machine system is shown by taking a sandbox to provide services. As shown in FIG. 1, a single-machine system includes an APP, a sandbox, and a device. Figure 5As shown, APP1 and APP2 are the calling parties, and APP3 is the called party. Each APP has a corresponding instance, and each instance is naturally isolated. The electronic device creates a sandbox for the called APP3, and APP3 runs its instance in the RAM resource in the sandbox, provides services for APP1 and APP2, and stores the application data generated in the process of running the instance in the database of the sandbox, which is the general term for the NVM resource in the sandbox. Since the database in the sandbox is shared, the data generated when the instance of APP3 in the sandbox provides services for APP1 and APP2 is saved in the database of the sandbox, and the data generated when APP1 and APP2 call APP3 can only be isolated by APP3. When the sandbox has a vulnerability or encounters malicious behavior, the data of APP1 and APP2 will be leaked. In addition, since the called party APP3 cannot distinguish the identities of different calling parties APP (APP1 and APP2), there are problems such as inability to trace the calling relationship and difficulty in recording audit logs.

[0201] In a distributed system, the authorization of the permission is only for the APP visible to the user, and the permission authorization cannot be performed on the functional components that are not directly perceived by the user. Therefore, when the calling party APP calls the functional component, there is also a data security risk.

[0202] In a distributed business scenario, when the calling party APP calls the functional component, if the method shown in Figure 5 is used, the called party functional component provides shared services for different calling party APPs in the form of a single instance in the sandbox, the functional component can generate application data from different devices and different calling parties, and may misuse or abuse the application data of each caller due to its own vulnerability or malicious behavior. In addition, since the called party functional component cannot distinguish the identities of different calling party APPs, there are problems such as inability to trace the calling relationship and difficulty in recording audit logs. For example, in the distributed business scenario shown in Figure 4 , a sandbox is created for the video call capability unit in the smart screen, but the video call capability unit in the smart screen can simultaneously obtain the data of the "online class" in the smart phone and the application data of the instant messaging application, and the two kinds of data may be leaked.

[0203] Embodiments of the present application provide an access control method, an electronic device and a system, which are used to solve the problems of misuse, confusion, misuse or leakage of the memory and application data of each calling party in a calling event. The access control method can be applied to a communication system including a plurality of electronic devices.

[0204] According to the method provided in the application, one same invoker can enable multiple sandboxes, and use different sandbox running instances to provide services for different invokers. Due to the natural isolation property between the sandboxes, different sandboxes cannot access memory data and application data of each other, so that a system-level data security mechanism can be provided, and the problems of misuse, abuse and leakage of data of each invoker are avoided, and data security is ensured.

[0205] Implementing the access control method provided in the application can support different instances running in different sandboxes when the invoker provides services for different invokers, and the memory data between different instances is kept isolated, so that the risk of misuse, confusion, abuse or leakage of data of each invoker is more effectively reduced, and data security is ensured.

[0206] The following exemplary introduces a software system architecture of an electronic device 100 provided in an embodiment of the application.

[0207] Figure 6 is a software architecture block diagram of the electronic device 100 provided in an embodiment of the application. The software system of the electronic device 100 can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture or a cloud architecture, etc. Exemplarily, the software system of the electronic device 100 includes but is not limited to or other operating systems.

[0208] The layered architecture divides the software system into several layers, and each layer has a clear role and division of labor. Layers communicate with each other through software interfaces (application programming interfaces, APIs). In some embodiments, as Figure 6 indicated, the software architecture of the electronic device 100 can include an application layer and an internal module layer, etc.

[0209] As Figure 6 indicated, the application layer can include a series of APPs and functional components. The application layer can include system applications and third-party non-system applications. Exemplarily, the application program layer can include but is not limited to a desktop, a camera, a gallery, a call, a navigation, a WLAN, a Bluetooth, music, multiple PA, FA, etc.

[0210] The internal module layer can provide application programming interfaces and functional support for the APPs and PA / FA of the application layer. The internal module layer can include some pre-defined functions and / or functional modules / services. The modules of the internal module layer can cooperate to manage the discovery, registration, query, migration of the application or functional component, and manage the creation, invocation of the application or functional component instance, etc. These modules can cooperate with other modules in the electronic device to implement the access control method provided in the application embodiment.

[0211] Exemplarily, the internal module layer can include, but is not limited to, an application information management module, an application startup management module, an instance management module, an application scheduling module, a permission management module, a calling relationship management module, a calling relationship library, an application file management module, and the like.

[0212] The application information management module is configured to manage information of each APP or functional component installed in the electronic device 100, and facilitate discovery, registration, installation, uninstallation, and the like of each APP / PA / FA. For example, a UID is assigned to each APP or functional component, a PID is assigned to each instance in a running state, and the like. For another example, registration information of each APP or PA / FA is managed, such as obtaining, recording, and managing an identifier of each APP / PA / FA, and an identifier of an electronic device on which the APP / PA / FA is deployed, and the like, to facilitate querying of the registration information and the like.

[0213] The application startup management module is configured to manage startup of each application program or functional component. For example, when the electronic device 100 receives a request of another device to call an application program, the application startup management module can start the application program.

[0214] The instance management module is responsible for dynamically starting or creating an instance according to information of a calling party. Specifically, when different devices and / or different calling parties request to call an application or functional component in the electronic device 100, the instance management module will enable an instance of the application or functional component for each of the different devices and / or different calling parties, and each instance provides services for the different devices and / or different calling parties. The instance management module is also configured to manage a life cycle of each enabled instance, such as starting, stopping, destroying, and restarting the instance, and the like.

[0215] The application scheduling module can be responsible for managing calling between APPs / PA / FA, such as being configured to initiate a calling request of a calling party to a called party. For example, an APP sends a calling request of a PA to the application scheduling module under triggering of a user operation, and then the application scheduling module can analyze and process the calling request to obtain an identifier of the APP, an identifier of the called PA, and corresponding request parameters.

[0216] The permission management module can be used to manage permission information of each APP / PA / FA, and is responsible for controlling permission of a calling party to call a called party and access permission of each APP / PA / FA to system resources. The permission management module can also be used to synchronize permission information and / or authorization information of APP / PA / FA respectively deployed in a plurality of terminal devices in the same distributed system. The permission management module can also be used to generate and provide permission-related prompt information to a user. In some embodiments, when the permission management module obtains an APP of an instance that has no permission to call to initiate a call request to the instance, the permission management module can ask the user whether to grant permission, change permission, or delete a malicious APP.

[0217] The call relationship management module is responsible for maintaining a plurality of groups of calling parties and called parties, and storing the call relationship in a call relationship database.

[0218] The call relationship database can be used to store a plurality of groups of calling parties and called parties. Each group of call relationship can include a call relationship identification (ID), calling party information, and called party information. The calling party information can include a calling party name, a device ID, a user identification (UID), and a developer signature. The called party information can include a called party name, a device ID, a UID of an instance, and a process identification (PID) of the instance.

[0219] Referring to Table 1 below, two groups of call relationships are exemplarily shown.

[0220]

[0221] Table 1

[0222] As can be seen from Table 1, the two groups of call relationships are that APP1 on the electronic device 100 and APP2 on the electronic device 200 respectively call a function component 3 in the electronic device 300. The electronic device 300 will enable two instances of the function component 3 to provide services for APP1 and APP2, respectively.

[0223] The call relationship shown in Table 1 can be stored not only in the electronic device where the called party is located, but also in the electronic device where the calling party is located, which is not limited here.

[0224] The sandbox management module is responsible for managing instances in the sandbox and application data generated by the instances, and storing the application data generated by the instances in the sandbox in the form of a directory. In order to save resources, different instances can run in the same sandbox, or different instances in the same sandbox can provide services for multiple calling parties. The application isolates the application data generated by different service instances in the same sandbox in the form of a directory. Different directories correspond to different identifiers. The identifier of a specific directory can be a calling party name, a device ID, a user identification (UID), a developer signature, a called party name, a device ID, a UID of an instance, a process identification (PID) of an instance, etc. The identifier of the directory can be a combination of the above identifiers, such as a combination of the developer signature and the called party identifier. The sandbox management module stores different data under different directories according to different identifiers, which facilitates searching and maintenance.

[0225] The above introduction to the software architecture of the electronic device 100 is only an example. It can be understood that the software architecture illustrated by the embodiments of the application does not constitute a specific limitation on the present application. In some other embodiments of the application, the software architecture of the electronic device 100 can include more or fewer modules than those illustrated, or some modules can be combined, or some modules can be split, or different architectural arrangements. The illustrated components can be implemented in hardware, software, or a combination of software and hardware.

[0226] The following describes a model of access control provided by an embodiment of the application.

[0227] As shown in one embodiment, Figure 7 In one embodiment, the distributed system can be installed with: a calling party APP1, a calling party APP2, and a called party functional component 3. The APP1, the APP2, and the functional component 3 can be installed in the same device or different devices in the distributed system, which is not limited in the embodiment. The APPs and / or functional components in the same distributed system can call each other. The called party functional component 3 can be an FA or a PA. The embodiment does not limit the types of calling parties and called parties. For example, in some other embodiments, the calling party is not limited to an APP, but can also be implemented as another functional component. The called party is also not limited to a functional component, but can also be implemented as an APP. An APP can call a functional component, a functional component can call another functional component, an APP can call another APP, and a functional component can call an APP.

[0228] The electronic device creates different sandboxes for different instances of the callee, and the different sandboxes have independent running environments, that is, the virtual system has independent RAM and NVM resources, allowing the instance to run therein. The sandbox can be created after the electronic device receives a call request, or can be created after the electronic device establishes a call relationship, which is not limited herein. Since the sandbox has an independent running environment, the memory data and application data between different sandboxes are isolated, ensuring high security and data traceability of the instance running.

[0229] As shown in Figure 7 APP1 and APP2 call the function component 3 respectively, and at the same time, the function component 3 itself is also running. The electronic device where the function component 3 is located can create three instances of the function component 3 and the corresponding three sandboxes, that is, function component 3 instance 1, function component 3 instance 2, function component 3 instance 3, sandbox 1, sandbox 2, and sandbox 3. Among them, the function component 3 instance 1 can provide services for the caller APP1 instance, the function component 3 instance 2 can provide services for the caller APP2 instance, and the function component 3 instance 3 can provide services for the function component 3 itself. The function component 3 instance 1 runs in the sandbox 1, the function component 3 instance 2 runs in the sandbox 2, and the function component 3 instance 3 runs in the sandbox 3. In this way, relying on the isolation property between the sandboxes, the memory data and application data of the instance 1 providing services for the caller APP1, the instance 2 providing services for the caller APP2, and the function component 3 itself can be isolated, effectively reducing the risk of misuse, confusion, and leakage of data of each function component.

[0230] In addition, while the caller calls the callee instance, each electronic device can record the call event of the current caller calling instance and the sandbox running the instance into the audit log and synchronize it to the distributed system, which is convenient for subsequent tracing of the call event, such as finding the reason after attack detection, or finding the reason for possible data security incidents or security vulnerabilities. The call event can include call event time, call relationship ID and other information.

[0231] Figure 7 The example in the figure has two call relationships: APP1 calls the function component 3, and APP2 calls the function component 3. The devices where APP1, APP2 and the function component 3 are located can respectively record and maintain the call relationship, and synchronize it to the distributed system, which can facilitate the tracing of the cause when problems occur subsequently, and reduce security risks.

[0232] The following describes a method for access control provided by an embodiment of the present application.

[0233] Embodiment one

[0234] This embodiment takes the example that the invoker and the callee are both deployed on the same electronic device 100 for illustration.

[0235] The electronic device 100 can be a standalone electronic device (a single machine) or an electronic device in a distributed system. The electronic device 100 can also be referred to as a first device.

[0236] The electronic device 100 can be installed with various APPs and functional components. The examples provided in this embodiment do not constitute any limitation on other embodiments of the present application.

[0237] Figure 8 is a method flowchart of access control provided by an embodiment of the present application, and specifically includes the following steps:

[0238] S101 The electronic device 100 initiates a first invocation request, and the first invocation request is used for the first invoker to request the callee to provide a first service.

[0239] The first invocation request can include the first invoker, the callee, and the indication information of the first service.

[0240] The embodiments of the present application do not make any limitation on the type and content of the first service. For example, the first invoker can request to access a first resource in the electronic device 100 through the callee. The first resource can include software resources (such as a beautifying algorithm, a positioning function, and an audio / video codec function) of the electronic device 100, or can include hardware resources (such as a camera, an audio device, and a display screen).

[0241] The embodiments of the present application do not make any limitation on the type of the invoker and the callee. The type of the invoker can include but is not limited to an APP, a PA, and a FA, and the type of the callee can include but is not limited to an APP, a PA, and a FA. For example, an APP can invoke a functional component PA / FA, the functional component PA / FA can also invoke other functional components PA / FA, the APP can also invoke other APPs, and the functional component PA / FA can also invoke APPs. For example, the invoker can be a chat APP, and the callee can be a positioning PA providing a positioning function. When the chat APP needs to obtain position information, the positioning PA needs to provide a positioning function service, and at this time, the chat APP can initiate an invocation request to the positioning PA.

[0242] The electronic device 100 can initiate the first invocation request in response to a received user operation, or can autonomously initiate the first invocation request, which is not limited herein. In some embodiments, the electronic device 100 can display a user interface of the invoker, and a user touch operation input by a user in the user interface can be detected by an input device such as a touch sensor, and then the electronic device 100 can initiate the first invocation request of the invoker to the invokee in response to the user touch operation.

[0243] In some embodiments, the invokee can be pre-installed in the electronic device 100. In other embodiments, after obtaining the first invocation request, the electronic device 100 can download and install the invokee from the network if it is detected that the invokee does not exist, or the electronic device 100 can obtain, download and install the invokee from other electronic devices in a distributed system if the electronic device 100 is in the distributed system, which is not limited in the embodiments of the present application.

[0244] In some embodiments, before the electronic device 100 initiates the first invocation request, the electronic device 100 needs to confirm that the first invoker has the permission to access the invokee, and the first invoker has the permission to access the first service.

[0245] S102 The electronic device 100 detects whether there is a first sandbox that can provide services for the first invoker, and if not, step S103 is performed, and if so, step S104 is performed.

[0246] In the present embodiment, the invokee can provide different sandboxes for different invokers. Therefore, after obtaining the first invocation request, the electronic device 100 can first detect whether there is a first sandbox that provides services for the first invoker.

[0247] Since the sandbox occupies many system resources, running multiple sandboxes will occupy many resources in the electronic device 100, and the resources allocated to the sandbox by the electronic device cannot be fully utilized inside the sandbox. Therefore, the invokers can be clustered by the sandbox, specifically, the invokers can be clustered according to the invoker information, and the instances of services of the invokers with the same invoker information run in the same sandbox. The invoker information can be included in the first invocation request of step S101.

[0248] The invoker information can include one or more of the following: an application identifier (APP ID) of the invoker, a user identifier (user ID, UID) of the invoker, a developer signature of the invoker, an account identifier (account ID) of the object device where the invoker is located, a device identifier (device ID) of the object device, an identifier (system ID) of the distributed system where the invoker is located, and the like. Among them:

[0249] APP ID, which can be used to identify the APP or functional component.

[0250] Developer signature, which can be used to identify the developer of the APP or functional component.

[0251] UID, which can be used to identify the user to which the APP or functional component or instance belongs. In general, the electronic device assigns different UIDs to different APPs or functional component or instances installed on the electronic device for distinction. For example, the electronic device can assign UIDs to different APPs in one data range (e.g., 10000-40000), and assign UIDs to different instances of functional components in another data range (e.g., 40001-50000).

[0252] In some embodiments, the electronic device can assign the same UID to different APPs or functional components developed by the same developer. In other embodiments, the electronic device can also assign different UIDs to different APPs or functional components developed by the same developer. In one example, when a first APP is installed, the electronic device assigns a UID of the first APP as a third UID, a second APP has the same developer signature as the first APP, and when the second APP is installed, the second APP indicates that the same UID as the first APP is used, the electronic device can assign the third UID to the second APP as well. The same APP or functional component can have different UIDs in different electronic devices. The present embodiments do not limit the manner or rule of assigning UIDs to different APPs or functional components or instances by the electronic device.

[0253] account ID, which can be used to identify the user currently logged into the electronic device, for example, a Huawei account.

[0254] device ID, which can be used to identify the device. The device ID can be, for example, the name, serial number, media access control (MAC) address, or the like of the device.

[0255] system ID, which can be used to identify the distributed system in which the current electronic device is located. In one implementation, instances can be process-isolated based on UIDs. That is, instances are distinguished by UIDs, and different instances are assigned different UIDs. Different UIDs provide services for different calling parties.

[0256] Taking the developer signature as an example, when the calling parties are "Huawei Mall" and "Huawei Music", the electronic device determines to use the same sandbox to provide services for the two APPs according to the developer signatures in the two APPs "Huawei Mall" and "Huawei Music".

[0257] S103 The electronic device 100 creates the first sandbox.

[0258] If no first sandbox of the callee available for the first caller is detected, the sandbox creation module of the electronic device 100 can create a first sandbox dedicated to the first caller. After the sandbox is created, the electronic device 100 can bind the sandbox with the caller information.

[0259] The first sandbox is a new independent running environment. After the electronic device 100 creates the first sandbox, the first instance needs to be run in the first sandbox to provide services for the caller through the first instance in the first sandbox. The specific instance running process is described in step S104.

[0260] For example, the sandbox can be executed by existing sandbox software such as Sandboxie, Oracle VM VirtualBox, VMware, etc., or can be created by the controller of the electronic device to isolate RAM and NVM resources, which is not limited here.

[0261] S104 The electronic device 100 runs the first instance in the first sandbox.

[0262] The first instance of the callee is run in the environment of the first sandbox, and the application data generated by the first instance of the callee is saved in the NVM of the first sandbox. For the case that the callers with the same caller information share a sandbox in step S102, the electronic device 100 can create different instances or share the same instance for different callers in the first sandbox through the instance management module thereof, which is described in steps S1041-S1042. At the same time, for the application data generated by the instance running in the sandbox, the electronic device 100 allocates different directory identifiers for the callers with the same caller information through the sandbox management module thereof, and manages the application data of different callers in the form of directory identifiers. For example, the "Huawei Appstore" and the "Huawei Music" with the same developer signature start two instances of "Huawei Appstore" and "Huawei Music" in the first sandbox, and store the application data in the NVM of the first sandbox. The data in the NVM is managed through different directories. For example, the caller information is used as the directory identifier, such as the directory identifier of "Huawei Appstore" is "Huawei Appstore" and the directory identifier of "Huawei Music" is "Huawei Music".

[0263] Before running the first instance in step S104, the method further includes:

[0264] S1041The electronic device 100 detects whether a first instance of the callee that can provide services for the first invoker exists, and if not, step S1042 is performed, and if so, step S104 is performed.

[0265] In this embodiment, the callee can provide different instances for different invokers. Therefore, after obtaining the first invocation request, the electronic device 100 can first detect whether a first instance of the callee that provides services for the first invoker already exists.

[0266] In specific implementations, the electronic device 100 can store a plurality of sets of invocation relationships, and the plurality of sets of invocation relationships record invocation events of a plurality of sets of invokers enabling instances, i.e., different instances providing services for different invokers. These invocation relationships can be stored in an invocation relationship library in the electronic device 100, facilitating the electronic device 100 to subsequently query whether an instance that provides services for an invoker already exists.

[0267] Each set of invocation relationships can include invoker information, instance information of the callee, an invocation relationship identification (ID), and the like. Call relationship

[0268] In some embodiments, the invocation relationship can indicate invocation permission. That is, a set of invocation relationships can indicate that the invoker has permission to invoke the instance of the callee.

[0269] The invocation relationship ID can be used to identify different invocation relationships, facilitating the electronic device 100 to identify. For example, in the two sets of invocation relationships shown in Table 1, the invocation relationship ID of APP1 invoking the function component 3 is 1, the invocation relationship ID of APP2 invoking the function component 3 is 2, and similarly, each set of invocation relationships is assigned a unique invocation relationship ID, facilitating identification and query, and can be shared with other electronic devices or synchronized to a distributed system.

[0270] In some embodiments, when the instance of the callee is created, the electronic device where the callee is located can record the invocation relationship, or when the invoker sends an invocation request, the electronic device where the invoker is located can also record the invocation relationship.

[0271] In some embodiments, for the same invocation relationship, the device where the invoker is located and the device where the callee is located can share the same invocation relationship ID. The invocation relationship ID can be assigned by the subject device or the object device, and shared with the other device.

[0272] ​In some embodiments, after an electronic device records a calling relationship, the calling relationship can be synchronized to a distributed system, and other devices in the distributed system can obtain the calling relationship. The caller information can include an application identifier (APP ID) of the caller.

[0273] The caller information can further include one or more of a user identifier (user ID, UID) of the caller, a developer signature of the caller, an account identifier (account ID) of a subject device where the caller is located, a device identifier (device ID) of the subject device, an identifier (system ID) of a distributed system where the caller is located, and the like.

[0274] The instance information of the callee can include a process identifier (process ID, PID) of the instance and a UID of the instance. The PID is an identity identifier of the instance, and an electronic device assigns a unique PID to each instance when the electronic device runs the instance. Different instances in the electronic device correspond to different PIDs. When each instance is created, the electronic device also assigns a UID to each instance. The UIDs of different instances of the same callee can be different or the same, which is determined according to the assignment of the electronic device.

[0275] For example, the electronic device 100 can assign a first PID and a first UID to a first instance and assign a second PID and a second UID to a second instance. For another example, when a callee creates a second instance in response to a second calling request of a second caller, the second calling request indicates that the second UID of the second instance is the same as the first UID of the first instance, and the electronic device assigns the second UID of the second instance to be the same as the first UID of the first instance.

[0276] The instance information of the callee can further include one or more of an application identifier (APP ID) of the callee, a user identifier (user ID, UID) of the callee, a developer signature of the callee, an account identifier (account ID) of an object device where the callee is located, a device identifier (device ID) of the object device, an identifier (system ID) of a distributed system where the callee is located, and the like. Among them:

[0277] In another embodiment, the instances can be process-isolated based on PIDs. That is, the instances are distinguished by PIDs, and different instances are assigned different PIDs. The instances with different PIDs provide services for different invokers. For example, in some examples, a first instance and a second instance are different instances of the callee, the first instance and the second instance are assigned the same UID, but the first instance and the second instance are assigned different PIDs, and the first instance and the second instance provide services for different invokers, respectively. Process-isolation based on PIDs can ensure more strict and secure isolation of data and / or processes than process-isolation based on UIDs.

[0278] The above-described process-isolation based on UIDs and process-isolation based on PIDs are only examples and do not limit other embodiments of the present application.

[0279] In some embodiments, different invokers can be distinguished according to one or more of the above-described invoker information. That is, different invokers are distinguished according to one or more of the following: an application identifier (APP ID) of the invoker, a UID of the invoker, a developer signature of the invoker, an account identifier (account ID) of the subject device where the invoker is located, a device identifier (device ID) of the subject device, an identifier (system ID) of the distributed system where the invoker is located, and the like. When one or more of the above-described information is different, the invokers can be distinguished.

[0280] In some embodiments, different invokers with the same developer signature can indicate to the callee that they share the same instance. In this way, data interaction between applications or functional components of the same developer can be facilitated while ensuring isolation of data / processes, and memory occupation and CPU consumption can be saved.

[0281] In addition to the developer signature, different invokers can also share the same instance according to other indication information, such as an APP ID, an account ID, a device ID, a system ID, and the like of the invoker, which are not listed one by one here.

[0282] In some embodiments, in order to make the calling relationship more rigorous and accurate, the caller information and the callee information of the calling relationship can include multiple items. For example, in an example, the first caller and the callee are in a distributed system, and in order to more rigorously verify the calling relationship, in addition to the APP ID of the first caller and the UID and / or PID of the first instance of the callee, the calling relationship of the first caller and the callee can record the subject device ID where the first caller is located, the object device ID where the callee instance is located, and the like, so as to avoid that the application or the functional component on other electronic devices in the distributed system which can have the same APP ID as the first instance incorrectly or maliciously calls the first instance, thereby achieving more strict access control.

[0283] In the embodiments of the present application, the first calling request of S101 can carry the first caller information, so that the electronic device 100 finds and judges whether the first instance of the callee corresponding to the first caller exists in the calling relationship library.

[0284] If S1041 judges no, S1042 is executed, and if S1041 judges yes, S104 is executed.

[0285] S1042 The electronic device 100 creates the first instance, and then executes step S104.

[0286] If no first instance of the callee available for the first caller is detected, the instance creation module of the electronic device 100 can create a first instance dedicated to providing services for the first caller, and perform permission binding.

[0287] The first instance can be created in the first sandbox or in the operating system of the electronic device, and then moved to the sandbox for running.

[0288] The first instance is a specific instance of the callee, and the first instance provides the same function, service and data as other instances of the callee, but has different calling permissions. For example, if the first instance only grants the first caller the calling permission, other applications or functional components have no permission to call the first instance.

[0289] The electronic device 100 can record and save the calling relationship and the calling permission of the first instance called by the first caller when creating the first instance. For specific description, reference can be made to the related description in S1041.

[0290] In some embodiments, the electronic device 100 needs to authenticate the permission. The electronic device 100 can query the permission information of the first calling party and the called party, determine whether the first calling party has the permission to call the first instance of the called party, and whether the first calling party has the permission to access the first service, and whether the first instance is the instance that the first calling party needs to call. If it is confirmed that the first calling party has the permission to call the first instance and / or access the first service, the first instance is run, and if not, a result of no calling permission is returned to the first calling party. In some embodiments, the calling relationship can indicate whether the first calling party has the permission to call the first instance.

[0291] In some embodiments, the step of authenticating whether the first calling party has the permission to call the first instance and / or access the first service can be performed before running the first instance, or before creating the first instance, or before initiating the first calling request. The time condition of the authentication in the embodiments of the present application is not limited, and the authentication step can be performed at any time point before running the first instance, or even when the first instance is running, and the permission can be queried at any time.

[0292] Once it is found that the first calling party has no permission to call the first instance of the called party, the electronic device 100 returns a result of no calling permission to the first calling party, ends the current calling event, and does not continue the subsequent steps.

[0293] The creation of the instance in this step and the creation of the sandbox in step S103 have no sequence, that is, the sandbox can be created first, and then the instance is created in the sandbox; or the instance can be created first in the electronic device, and then the sandbox is created, and the instance is run in the sandbox.

[0294] The confirmation of the permission in this step is to avoid that an application or a functional component without the permission to call the first instance maliciously or incorrectly calls the first instance and accesses the resources thereof, and to reduce the security risk.

[0295] S105 The electronic device 100 responds to the first calling request received in S101, and provides the first service for the first calling party through the first instance in the first sandbox.

[0296] Specifically, after it is confirmed that the first calling party has the permission to call the first instance, and it is confirmed that the first instance is indeed the instance that the first calling party needs to call, the electronic device 100 can run the first instance in the first sandbox, respond to the first calling request, allow the first calling party to access the first resource in the first sandbox provided by the first instance, and return the access result to the first calling party. The first resource provided by the electronic device 100 can include software resources, hardware resources, and the like allocated to the first sandbox.

[0297] When the first invoker invokes the first instance in the first sandbox, the electronic device 100 can record the calling event of the first invoker calling the first instance into the audit log, so as to facilitate subsequent tracing of the calling event, such as facilitating finding the reason after attack detection, or finding the reason for a possible data security incident or security vulnerability. The calling event can include information such as a calling event occurrence time and a calling relationship ID.

[0298] After obtaining the instruction that the first invoker ends calling the callee, the electronic device 100 can release the service process of the first instance in the first sandbox, end the first instance providing the first service to the first invoker, and improve the resource utilization rate of the first sandbox.

[0299] Optionally, after step S105, when the first invoker no longer needs to call the resources of the electronic device 100, the electronic device 100 can recycle the resources of the first sandbox, and improve the resource utilization rate of the electronic device 100.

[0300] S106 The electronic device 100 initiates a second calling request, and the second calling request is used for a second invoker requesting a callee to provide a second service. If the electronic device 100 detects that the callee can provide the service for the second invoker, the electronic device 100 runs a second instance in a second sandbox, provides the second service for the second invoker, and records a calling event of the second invoker calling the second instance. The specific process can refer to the description of the first invoker calling the first instance in the first sandbox in steps S101-S105, which will not be described here.

[0301] In this embodiment, the callee can run different corresponding instances in different sandboxes according to different invokers, and provide different services. For example, the callee can run a first instance in a first sandbox and a second instance in a second sandbox, the first instance in the first sandbox provides a first service for a first invoker, and the second instance in the second sandbox provides a second service for a second invoker. In this way, the sandbox mechanism can be used to isolate the permissions and data between different instances, and the data security is further improved.

[0302] S107 The electronic device 100 initiates a third calling request, and the third calling request is used for the first invoker requesting the callee to provide a third service. If the electronic device 100 detects that the first sandbox of the callee can provide the service for the first invoker in the first sandbox, the electronic device 100 runs the first instance in the first sandbox, provides the third service for the first invoker in the first sandbox, and records a calling event of the first invoker calling the first instance. The specific process can refer to the description of the first invoker calling the first instance in steps S101-S105, which will not be described here.

[0303] Optionally, in order to keep the memory data of the third service isolated from that of the first service, or to provide the third service and the first service in parallel, two first instances can be run in the first sandbox, and the application data generated by the two first instances can be isolated by directory identifier according to the different services.

[0304] The same applies to the call request from the second caller as in step S106, and will not be repeated here.

[0305] Furthermore, during the execution of the above steps, the electronic device 100 can query permission information to determine whether the first caller has permission to call the callee. If so, the above steps are executed; otherwise, a result indicating no calling permission is returned to the first caller. Specifically, the permission information query can be performed before any of steps S101-S107.

[0306] It should be noted that the three call requests in steps S101-S105, S106 and S107 have no order of initiation and can be initiated in any order or simultaneously.

[0307] Before any of steps S101-S107, the electronic device 100 may query the permission information of the first caller and the callee to confirm whether the call relationship or call permission indicates that the first caller has the permission to access the callee, and whether the first caller has the permission to access the first service, and also confirm whether the first instance is the instance that the first caller needs to call.

[0308] If it is found that the first caller does not have permission to call the first instance, the electronic device 100 can return a result indicating that the call failed due to lack of permission. This permission verification step is to prevent applications or functional components without the necessary permissions from maliciously or incorrectly calling the first instance and accessing its resources, thereby reducing security risks.

[0309] By implementing the method provided in Embodiment 1, when the callee provides services to different callers, different instances are run in different sandboxes. This ensures that permissions are isolated between different instances, and instances in different sandboxes cannot access each other's data. This avoids the problem of the callee abusing or misusing the caller's data and ensures data security.

[0310] In the embodiment, when the first invoker initiates different invocation requests to request the callee to provide additional services, the electronic device 100 can run the same instance to provide services in the same sandbox. For example, in step S107, the first invoker requests the callee to provide a third service, which is different from the first service requested by the first invoker in step S101. However, the callee can run the same first instance in the first sandbox for the same first invoker, and the first instance can provide the first service or the third service for the first invoker in response to the first invocation request or the third invocation request. The electronic device can store the application data generated by the first service and the application data generated by the third service in the form of a directory through the sandbox management module.

[0311] When the electronic device 100 runs an instance in the same sandbox, the memory data corresponding to the instance is generated. When the electronic device 100 runs multiple instances in the same sandbox, multiple memory data are generated, and the multiple memory data are isolated from each other and cannot access each other, that is, the instances in the sandbox are isolated from each other.

[0312] In some embodiments, different devices can be distinguished by the sandbox, that is, different invokers on the same device can share the same sandbox. In an example, the electronic device 100 initiates a fourth invocation request, and the fourth invocation request can carry: an indication of a third invoker, a callee, and a fourth service. The third invoker is installed in the electronic device 100, and the third invoker is an application APP or a functional component. In response to the fourth invocation request, the electronic device 100 runs the first instance in the first sandbox, and the first instance is also used to provide the fourth service for the third invoker. In this example, the third invoker and the first invoker can both invoke the first instance in the first sandbox.

[0313] Embodiment Two

[0314] It can be understood that the access control method provided in the application can also be implemented between multiple electronic devices in a distributed system, and the invoker and the callee initiating the invocation request can be deployed on different electronic devices.

[0315] After the devices in the distributed system establish a communication connection, the devices synchronize the function component information and APP information of other devices in the distributed system. Specifically, each device can synchronize the identifier of the function component and / or APP installed by itself, the device information (for example, the device identifier) of the device to the distributed system, which is visible to other devices, to facilitate subsequent mutual calling between the devices in the distributed system. The calling permission and / or the called permission of each function component or APP, that is, which calling parties can call the function component or APP and which other function components or APPs can be called by the function component or APP, can be preset and recorded on each electronic device and synchronized in the distributed system.

[0316] This embodiment takes an example in which the calling party and the called party are deployed on different electronic devices in the same distributed system.

[0317] In this embodiment, the calling party that initiates the calling request is deployed on the electronic device 100, and the called party is deployed on the electronic device 200. The electronic device 100 and the electronic device 200 are in the same distributed system.

[0318] Similarly, the types of the calling party and the called party are not limited in this embodiment. The types of the calling party can include but are not limited to APP, PA, and FA, and the types of the called party can include but are not limited to APP, PA, and FA. For example, an APP can call a function component PA / FA, a function component PA / FA can call other function components PA / FA, an APP can call other APPs, and a function component PA / FA can call an APP.

[0319] The multiple terminal devices in the same distributed system can synchronize the registration information, the permission information, and the calling relationship between APPs, PAs, and FAs, and the like of the APPs, PAs, and FAs deployed by the terminal devices. Among them,

[0320] The registration information can be used to identify an application or a function component, and can include the identifier (APP ID) of the application or the function component, the identifier (device ID) of the electronic device where the application or the function component is located, the account identifier (account ID) of the electronic device where the application or the function component is located, and the like.

[0321] The permission information can include the calling / access permission and the called / access permission of the application or the function component, and the like.

[0322] The description of the calling relationship can refer to Embodiment 1, which is not described here again.

[0323] The examples provided in this embodiment do not constitute any limitation on other embodiments of the present application.

[0324] Figure 9is a method flowchart of access control provided by an embodiment of the present application, and specifically includes the following steps:

[0325] S201 The electronic device 100 sends a first access request to the electronic device 200, where the first access request is used by the electronic device 100 to request the first service provided by the callee to the first caller from the electronic device 200.

[0326] The first caller is deployed on the electronic device 100, and the callee is deployed on the electronic device 200.

[0327] Before the electronic device 100 sends the first access request to the electronic device 200, the electronic device 100 can generate a first call request, where the first call request is used by the first caller to inform the electronic device 100 that the first service is needed by the callee.

[0328] Embodiments of the present application do not make any limitation on the type and content of the first service. For example, the first caller of the electronic device 100 requests the callee of the electronic device 200 to provide a first resource. The first resource can include a software resource (such as a beauty algorithm, a positioning function, and an audio and video codec function) of the electronic device 200, or a hardware resource (such as a camera, an audio device, and a display screen).

[0329] The electronic device 100 can obtain the identifier of the electronic device 200 where the callee is located according to the first call request.

[0330] In some embodiments, the first call request can include the identifier of the electronic device 100, the identifier of the first caller, the identifier of the electronic device 200, the identifier of the callee, and the like. The electronic device 100 can obtain the identifier of the electronic device 200 where the callee is located according to the first call request.

[0331] In another embodiment, the identifier of the electronic device 200 where the callee is located is not included in the first call request. Then, the electronic device 100 can query the registration information of the callee in the distributed system according to the identifier of the callee after obtaining the identifier of the callee, so as to obtain the identifier of the electronic device 200. Embodiments of the present application do not make any limitation on the way in which the electronic device 100 obtains the identifier of the electronic device 200.

[0332] After obtaining the identifier of the electronic device 200 where the callee is located, the electronic device 100 can initiate the first access request to the electronic device 200, where the first access request can carry the ID of the electronic device 100, the ID of the electronic device 200, the ID of the first caller, the ID of the callee, an instruction of requesting the first service, and the like.

[0333] The electronic device 100 can initiate the first access request to the electronic device 200 in response to the received user operation, or can autonomously initiate the first access request to the electronic device 200, which is not limited here. In some embodiments, the electronic device 100 can display a user interface of the first caller, and the user operation input by the user in the user interface can be detected through a touch sensor or other input device. Then, the electronic device 100 can initiate the first access request to the electronic device 200 in response to the user touch operation.

[0334] In some embodiments, the callee can be pre-installed in the electronic device 200. In other embodiments, the electronic device 200 can download and install the callee from the network after receiving the first access request sent by the electronic device 100, or can obtain, download and install the callee from the electronic device 100 or other electronic devices in the distributed system, which is not limited in the embodiments of the present application.

[0335] In some embodiments, before the electronic device 100 sends the first access request to the electronic device 200, the electronic device 100 needs to confirm that the first caller has the permission to access the callee, and the first caller has the permission to access the first service.

[0336] S202 After obtaining the first access request sent by the electronic device 100, the electronic device 200 detects whether there is a first sandbox of the callee that can provide services for the first caller, and if not, step S203 is performed, and if so, step S204 is performed.

[0337] In the present embodiment, the callee can provide different instances in different sandboxes for different callers. Therefore, after obtaining the first access request, the electronic device 200 can first detect whether there is a first sandbox of the callee that provides services for the first caller of the electronic device 100.

[0338] Specifically, the electronic device 200 can determine whether there is a first sandbox according to the caller information in the first access request, and cluster the callers with the same caller information. The specific steps are the same as step S102, which will not be repeated here.

[0339] S203 The electronic device 200 creates a first sandbox.

[0340] If no sandbox environment is detected that can be called by the first caller of the electronic device 100, the instance creation module of the electronic device 200 can create a first sandbox that provides services for the first caller of the electronic device 100, and is bound with the first caller information.

[0341] The specific sandbox creation process can be seen from step S103, which will not be described here.

[0342] S204 The electronic device 200 runs the first instance in the first sandbox.

[0343] The first instance of the callee is run in the environment of the first sandbox, and the application data generated by the first instance of the callee is saved in the NVM of the first sandbox. For the case that the callees with the same caller information share one sandbox in step S202, the electronic device 100 can create different instances or share the same instance for different callees in the first sandbox through the instance management module thereof, which can be seen from steps S1041-S1043. Meanwhile, for the application data generated by the instance running in the sandbox, the electronic device 100 allocates different directory identifiers for the callees with the same caller information through the sandbox management module thereof, and manages the application data of different callees in the form of directory identifiers.

[0344] Before running the instance, step S204 further includes the process of creating the first instance by the electronic device 200, and the specific process of creating the instance can be seen from steps S1041-S1042, which will not be described here.

[0345] S205 The electronic device 200 provides the first service for the first callee in the electronic device 100 in response to the first access request.

[0346] The specific process of responding to the access request and recycling the resources after step S205 can be seen from step S105, which will not be described here.

[0347] Other electronic devices in the distributed system can send a second request to the electronic device, which can be seen from the following steps.

[0348] S206 The electronic device 300 initiates a second access request to the electronic device 200, and the second access request is used for the electronic device 300 to request the callee to provide a second service for the second callee. The second callee is deployed on the electronic device 300, and the callee is deployed on the electronic device 200. If the electronic device 200 detects a second sandbox of the callee that can provide a service for the second callee, the electronic device 200 runs a second instance in the second sandbox to provide a second service for the second callee of the electronic device 300, and records the calling event of the second instance of the electronic device 200 called by the second callee of the electronic device 300. The specific process can be referred to the description of the first instance of the first sandbox of the electronic device 200 called by the first callee of the electronic device 100 in steps S201-S205, which will not be described here.

[0349] In some other embodiments, the second invoker can also be deployed on the electronic device 100, or deployed on the electronic device 200.

[0350] In this embodiment, the callee can run different corresponding instances in different sandboxes according to different invokers, and provide different services. For example, the callee can create a first instance and a second instance, the first instance provides a first service for the first invoker, and the second instance provides a second service for the second invoker. The isolation of the sandboxes can ensure that the permissions and data of different instances are isolated, and the data security is further improved.

[0351] S207 In this embodiment, when the electronic device 100 initiates a third access request to the electronic device 200, the third access request is used to request the callee to provide a third service for the first invoker of the electronic device 100. If the electronic device 200 detects the first sandbox of the callee that can provide the service for the first invoker, the electronic device 200 runs the first instance in the first sandbox to provide the third service for the first invoker of the electronic device 100, and records the calling event of the first invoker of the electronic device 100 calling the first instance of the electronic device 200. The specific process can refer to the description of the first invoker of the electronic device 100 calling the first sandbox of the electronic device 200 in steps S201-S204, which will not be repeated here.

[0352] In this embodiment, when the first invoker of the electronic device 100 initiates different calling requests to the callee of the electronic device 200 to request the callee to provide another service, the electronic device 200 runs the same instance in the same sandbox to provide the service. For example, in step S206, the first invoker of the electronic device 100 requests the callee of the electronic device 200 to provide a third service, which is different from the first service requested by the first invoker of the electronic device 100 in step S201. However, the callee will run the same first instance for the same first invoker, and the first instance can respond to the first calling request or the third calling request to provide the first service or the third service for the first invoker.

[0353] It should be noted that the initiation of the three calling requests in steps S201-S205, S206 and S207 has no sequence, and can be initiated in any sequence or simultaneously.

[0354] By implementing the method provided in this embodiment two, when the callee deployed on different electronic devices provides services for different invokers, different instances in different sandboxes are run respectively, which can ensure the permission isolation between different instances, the sandboxes cannot access the memory data and application data of each other, and the problem of misuse or abuse of the application data of the invoker in the unified sandbox can be avoided, thereby ensuring the data security.

[0355] Optionally, the electronic device 200 can create multiple first instances for different services in the first sandbox, and isolate application data generated by the two first instances according to different services through directory identification.

[0356] The electronic device 100 can also be referred to as a first device, the electronic device 200 can also be referred to as a second device, the electronic device 300 can also be referred to as a third device, the first access request can also be referred to as a first request, the second access request can also be referred to as a second request, and the third access request can also be referred to as a third request.

[0357] In some embodiments, different invokers on the same device can share the same sandbox. In an example, the first device sends a fourth request to the second device, and the fourth request can carry: a third invoker, a called invoker, and indication information of a fourth service, where the third invoker is installed in the first device, and the third invoker is an application APP or a functional component. In response to the fourth request, the second device runs the first instance in the first sandbox, and the first instance is also used to provide the fourth service for the third invoker. In this example, the third invoker on the first device and the first invoker can both invoke the first instance in the first sandbox.

[0358] In some embodiments, the same invoker on different devices can share the same instance in the same sandbox. In an example, the fourth device initiates a fifth request to the second device, and the fifth request carries: the first invoker, the called invoker, and indication information of a fifth service, where the first invoker is installed in the fourth device. In response to the fifth request, the second device runs the first instance in the first sandbox, and the first instance is also used to provide the fifth service for the first invoker of the fourth device. In this example, the first invoker on the first device and the first invoker on the fourth device can both invoke the first instance.

[0359] In some embodiments, the same invoker on different devices can invoke different instances in the same sandbox. In an example, the first invoker and the second invoker are the same invoker. In this example, the first invoker of the first device can invoke the first instance in the first sandbox, and the first invoker of the second device can invoke the second instance in the first sandbox, where the first instance and the second instance are different. The first sandbox distinguishes application data of the first instance and the second instance through directory identification.

[0360] In some embodiments, different invokers on the same device can invoke different instances in the same sandbox. In one example, the first device and the third device are the same device. In this example, a first invoker of the first device can invoke a first instance in the first sandbox, and a second invoker of the first device can invoke a second instance in the first sandbox, the first instance being different from the second instance. The first sandbox identifies the application data of the first instance and the second instance by directory.

[0361] Embodiment Three

[0362] The access control methods in Embodiment One and Embodiment Two above, the electronic device runs different instances of the function component 3 to provide services for different invokers. Through the application of the sandbox mechanism, the data between different sandboxes is isolated, including memory data and application data, which guarantees the security of the data, especially the security of the application data. On this basis, in Embodiment Three, the sandbox mechanism is applied to the isolation of application data, and the specific system structure diagram is shown in FIG. 10.

[0363] In FIG. 10(A), different instances of the function component 3 are run in the electronic device to provide services for different invokers, and the application data generated by different instances is stored and managed by the sandbox. Since the instances are running, the memory data is naturally isolated, and the application data is stored by the sandbox, and different directory identifiers are set for different application data by the sandbox management module to manage the application data corresponding to different instances.

[0364] In FIG. 10(B), considering that the management of data in the same sandbox by directory identifier still has the problem of invoker security, APP1 may access the application data of different directory identifiers in the sandbox through the function component instance 1. In 10(B), different instances of the function component 3 are run in the electronic device to provide services for different invokers, and then different sandboxes are created for different instances to store and manage the application data generated by different instances.

[0365] Further, considering that creating a sandbox will occupy the resources of the electronic device, too many sandboxes will make the electronic device overloaded, and the resources in the sandbox are fixed after creation, and the resources of the sandbox cannot be fully utilized many times. In order to solve the above problems, the sandbox 1 and the sandbox 3 in FIG. 10(B) can be combined to isolate the data of all invokers and the application data generated by the function component 3 itself, as shown in FIG. 10(C). Inside the invoker data, the application data generated by different invokers is managed by directory identifier.

[0366] For the cases of FIG. 10(A) and FIG. 10(C) above, in Figure 6In the internal module layer of the sandbox, a data hosting service module can be added. When different calling parties call instances, the data hosting service module can be used to verify the legality of the calling party and the operation of the calling party. If the calling party is legal and operates normally, the sandbox provides storage and reading services for the application data of the corresponding instance of the calling party. As shown in FIG. 10(C), if the instance 1 of the functional component 3 providing services for the APP1 wants to access the data under the directory identifier of the instance 2 of the functional component 3, the data hosting service module will intercept such an operation to ensure the security of the application data in the sandbox.

[0367] The distributed system described above can be a standalone electronic device, or one or more electronic devices in a distributed system. The electronic device can be installed with various APPs and functional components. The examples provided in this embodiment do not constitute any limitation on other embodiments of the present application.

[0368] The types of the calling party and the called party are not limited in this embodiment. The types of the calling party can include, but are not limited to, APP, PA, and FA. The types of the called party can include, but are not limited to, APP, PA, and FA. For example, an APP can call a functional component PA / FA, the functional component PA / FA can call other functional components PA / FA, the APP can call other APPs, and the functional component PA / FA can call APPs. For example, the calling party can be a chat APP, and the called party can be a positioning PA providing positioning functions. When the chat APP needs to obtain location information, the chat APP needs to call the positioning PA to provide positioning function services.

[0369] The implementation manners described in the above embodiments are only exemplary and do not constitute any limitation on other embodiments of the present application. The specific internal implementation manners can be different according to the types of electronic devices, the types of operating systems, the programs used, and the interfaces called, and the embodiments of the present application do not constitute any limitation. The features and functions described in the embodiments of the present application can be implemented.

[0370] In the above embodiments, according to the context, the term "when" can be interpreted as meaning "if" or "after" or "in response to determining" or "in response to detecting". Similarly, according to the context, the phrase "upon determining" or "if detecting (the stated condition or event)" can be interpreted as meaning "if determining" or "in response to determining" or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)".

[0371] In the above embodiments, all or part of the methods can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the methods can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center through a wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes one or more available media sets. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state disk), etc.

[0372] Those of ordinary skill in the art understand that all or part of the processes in the above embodiments can be implemented by a computer program that instructs relevant hardware, which can be stored in a computer-readable storage medium and executed to include the processes of the above embodiments.

[0373] The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the above embodiments of the present application have been described in detail, those of ordinary skill in the art should understand that they can modify the technical solutions described in the above embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method of access control, characterized in that, The method is applied to a communication system, and the communication system comprises a first device, a second device and a third device, wherein the first device is installed with a first invoker, the second device is installed with a callee, and the third device is installed with a second invoker; the first invoker, the callee and the second invoker are application programs or function components, the application program is a program entity for implementing multiple functions, and the function component is a program entity for implementing a single function; The method comprises: The first device sends a first request to the second device, and the first request carries indication information of the first invoker, the callee and a first service; In response to the first request, the second device runs a first instance in a first sandbox, the first instance is an instance of the callee, and the first instance is used to provide the first service for the first invoker; The third device sends a second request to the second device, and the second request carries indication information of the second invoker, the callee and a second service; In response to the second request, the second device runs a second instance in a second sandbox, the second instance is an instance of the callee, and the second instance is used to provide the second service for the second invoker, and the second sandbox is different from the first sandbox; The first device initiates a third request to the second device, and the third request carries indication information of the first invoker, the callee and a third service; In response to the third request, the second device runs the first instance in the first sandbox, and the first instance is also used to provide the third service for the first invoker, or the second device runs a third instance in the first sandbox, and the third instance is used to provide the third service for the first invoker.

2. The method of claim 1, wherein, The method further comprises: The first device initiates a fourth request to the second device, and the fourth request carries indication information of a third invoker, the callee and a fourth service, wherein the third invoker is installed in the first device, and the third invoker is an application program APP or a function component; In response to the fourth request, the second device runs the first instance in the first sandbox, and the first instance is also used to provide the fourth service for the third invoker, or the second device runs a third instance in the first sandbox, and the third instance is used to provide the fourth service for the third invoker.

3. The method of claim 1, wherein, The method further comprises: A fourth device initiates a fifth request to the second device, and the fifth request carries indication information of the first invoker, the callee and a fifth service, wherein the first invoker is installed in the fourth device; In response to the fifth request, the second device runs the first instance in the first sandbox, and the first instance is also used to provide the fifth service for the first invoker of the fourth device, or the second device runs a third instance in the first sandbox, and the third instance is used to provide the fourth service for the third invoker.

4. The method of claim 1, wherein, The first invoker and the second invoker are the same.

5. The method of claim 1, wherein, The first device and the third device are the same device.

6. The method of claim 1, wherein, before the second device runs the first instance, the method further comprises: the second device detects whether the first sandbox exists, and if not, the second device creates the first sandbox; before the second device runs the second instance, the method further comprises: the second device detects whether the second sandbox exists, and if not, the second device creates the second sandbox.

7. The method of claim 6, wherein, the second device runs the first instance in the first sandbox comprises that the second device creates the first instance and runs the first instance in the first sandbox; the second device runs the second instance in the second sandbox comprises that the second device creates the second instance and runs the second instance in the second sandbox.

8. The method of claim 7, wherein, after the second device creates the first instance, the second device stores a first invocation relationship, the first invocation relationship comprising: information of the first invoker, information of the first instance, and an identifier of the first invocation relationship; after the second device creates the second instance, the second device stores a second invocation relationship, the second invocation relationship comprising: information of the second invoker, information of the second instance, and an identifier of the second invocation relationship.

9. The method of claim 8, wherein, after the first device sends the first request to the second device, the method further comprises that the first device stores the first invocation relationship; after the third device sends the second request to the second device, the method further comprises that the third device stores the second invocation relationship.

10. The method of claim 8, wherein, the information of the first invoker comprises one or more of: an application identifier of the first invoker, a user identifier UID of the first invoker, a developer signature of the first invoker, an account identifier of the first device where the first invoker is located, an identifier of the first device, and an identifier of the communication system where the first invoker is located; the information of the first instance comprises: a process identifier first PID of the first instance and a user identifier first UID of the first instance; the method further comprises: when the second device creates the first instance, the second device allocates the first PID or the first UID to the first instance.

11. The method of claim 7, wherein, the information of the first instance further comprises one or more of: an application identifier of the invoker, a user identifier UID of the invoker, a developer signature of the invoker, an account identifier of the second device where the invoker is located, an identifier of the second device, and an identifier of the communication system where the first instance is located.

12. The method of claim 1, wherein, the first request further carries an identifier of the first device and an identifier of the second device.

13. The method of claim 1, wherein, After the second device runs the first instance, the method further comprises: The second device generates a first result; The second device returns the first result to the first device; The first device processes the first result by running the first invoker.

14. The method of claim 1, wherein, Before the second device runs the first instance, the method further comprises: The second device confirms that the first invoker has the permission to access the first instance.

15. The method of claim 1, wherein, Before the second device runs the first instance, the method further comprises: The second device confirms that the first invoker has the permission to request the called party to provide the first service.

16. The method of claim 1, wherein, Before the first device sends the first request to the second device, the method further comprises: The first device confirms that the first invoker has the permission to access the called party.

17. The method of claim 1, wherein, The first device, the second device, and the third device are the same device.

18. The method of any of claims 1-17, wherein, The second device stores a mapping relationship between the first sandbox and the first invoker, and stores a mapping relationship between the second sandbox and the second invoker.

19. A method of access control, characterized by, The method is applied to a second device, and the second device is located in a communication system, the communication system comprising a first device, a second device, and a third device, wherein the first device is installed with a first invoker, the second device is installed with a called party, and the third device is installed with a second invoker; the first invoker, the called party, and the second invoker are application programs or function components, the application program is a program entity that implements multiple functions, and the function component is a program entity that implements a single function; The method comprises: The second device receives a first request sent by the first device, and the first request carries indication information of the first invoker, the called party, and a first service; In response to the first request, the second device runs a first instance in a first sandbox, the first instance being an instance of the called party, and the first instance being used to provide the first service for the first invoker; The second device receives a second request sent by the third device, and the second request carries indication information of the second invoker, the called party, and a second service; In response to the second request, the second device runs a second instance in a second sandbox, the second instance being an instance of the called party, and the second instance being used to provide the second service for the second invoker, the second sandbox being different from the first sandbox; The second device receives a third request sent by the first device, and the third request carries indication information of the first invoker, the called party, and a third service; In response to the third request, the second device runs the first instance in the first sandbox, and the first instance is also used to provide the third service for the first invoker, or the second device runs a third instance in the first sandbox, and the third instance is used to provide the third service for the first invoker.

20. The method of claim 19, wherein, The method further comprises: The second device receives a fourth request sent by the first device, and the fourth request carries: third invoker, the called party, and indication information of a fourth service, wherein the third invoker is installed in the first device, and the third invoker is an application program (APP) or a functional component; In response to the fourth request, the second device runs the first instance in the first sandbox, and the first instance is further configured to provide the fourth service for the third invoker, or the second device runs a third instance in the first sandbox, and the third instance is configured to provide the fourth service for the third invoker.

21. The method of claim 19, wherein, The method further comprises: The second device receives a fifth request sent by a fourth device, and the fifth request carries: the first invoker, the called party, and indication information of a fifth service, wherein the first invoker is installed in the fourth device; In response to the fifth request, the second device runs the first instance in the first sandbox, and the first instance is further configured to provide the fifth service for the first invoker of the fourth device, or the second device runs a third instance in the first sandbox, and the third instance is configured to provide the fourth service for the third invoker.

22. The method of claim 19, wherein, The first invoker and the second invoker are the same.

23. The method of claim 19, wherein, The first device and the third device are the same device.

24. The method of claim 19, wherein, Before the second device runs the first instance, the method further comprises: The second device detects whether the first sandbox exists, and if not, the second device creates the first sandbox; Before the second device runs the second instance, the method further comprises: The second device detects whether the second sandbox exists, and if not, the second device creates the second sandbox.

25. The method of claim 24, wherein, The second device runs the first instance in the first sandbox, comprising: the second device creates the first instance and runs the first instance in the first sandbox; The second device runs the second instance in the second sandbox, comprising: the second device creates the second instance and runs the second instance in the second sandbox.

26. The method of claim 25, wherein, After the second device creates the first instance, the second device stores a first invocation relationship, and the first invocation relationship comprises: information of the first invoker, information of the first instance, and an identifier of the first invocation relationship; After the second device creates the second instance, the second device stores a second invocation relationship, and the second invocation relationship comprises: information of the second invoker, information of the second instance, and an identifier of the second invocation relationship.

27. The method of claim 26, wherein, The information of the first invoker comprises one or more of the following: an application identifier of the first invoker, a user identifier UID of the first invoker, a developer signature of the first invoker, an account identifier of the first device where the first invoker is located, an identifier of the first device, an identifier of the communication system where the first device is located; The information of the first instance comprises a process identifier first PID of the first instance and a user identifier first UID of the first instance. The method further comprises: When the second device creates the first instance, the second device allocates the first PID or the first UID to the first instance.

28. The method of claim 26, wherein The information of the first instance further comprises one or more of the following: an application identifier of the first invoker, a user identifier UID of the first invoker, a developer signature of the first invoker, an account identifier of the second device where the first invoker is located, an identifier of the second device, an identifier of the communication system where the first instance is located.

29. The method of claim 19, wherein, The first request further carries an identifier of the first device and an identifier of the second device.

30. The method of claim 19, wherein, After the second device runs the first instance, the method further comprises: The second device generates a first result; The second device returns the first result to the first device, and the first result is used by the first device to run the first invoker process.

31. The method of claim 19, wherein, Before the second device runs the first instance, the method further comprises: The second device confirms that the first invoker has the permission to access the first instance.

32. The method of claim 19, wherein, Before the second device runs the first instance, the method further comprises: The second device confirms that the first invoker has the permission to request the first service provided by the first invoker.

33. The method of claim 19, wherein, The first device, the second device, and the third device are the same device.

34. The method of any of claims 19-33, wherein, The second device stores a mapping relationship between the first sandbox and the first invoker, and stores a mapping relationship between the second sandbox and the second invoker.

35. An electronic device, comprising: The electronic device comprises a communication device, a memory, and a processor coupled to the memory, a plurality of application programs, and one or more programs; the memory stores computer executable instructions, and the processor executes the instructions to enable the electronic device to implement the method of any one of claims 19 to 34.

36. A communication system, characterized by The communication system comprises a first device, a second device, and a third device, wherein the first device, the second device, and the third device cooperate to implement the method of any one of claims 1 to 18.

37. A computer-readable storage medium comprising instructions, wherein: When the instructions are executed on the electronic device, the electronic device executes the method of any one of claims 19 to 34.

38. A computer program product comprising instructions, wherein: When the computer program product is executed on the electronic device, the electronic device executes the method of any one of claims 19 to 34.

Images