CN117714275A

CN117714275A - Identity management method and related device for distributed application

Info

Publication number: CN117714275A
Application number: CN202310851090.4A
Authority: CN
Inventors: 章燕芳; 石可
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-07-11
Filing date: 2023-07-11
Publication date: 2024-03-15
Anticipated expiration: 2043-07-11
Also published as: CN117714275B

Abstract

The application provides an identity management method of a distributed application and a related device, which are applied to a scene that a first application of first electronic equipment calls a second application of second electronic equipment, and when the second electronic equipment judges that the available DUID of the first application does not exist, the second electronic equipment distributes the DUID for the first application. In the process of allocating the DUID for the first application, if the allocated DUID is judged to conflict with the UID of the installed application, a new DUID is allocated for the first application again. Therefore, the problem that the second electronic equipment cannot confirm the application identity of the calling party is avoided, and the validity of the DUID of the distributed application is improved, so that the success rate of cross-equipment calling is improved. Further, whether the number of the DUIDs exceeds the first preset number is judged, if so, the preset number of the DUIDs with earlier allocation time is recovered, so that the DUIDs are reallocated to other applications, and the phenomenon that the DUIDs cannot be allocated due to the exhaustion of the DUIDs is avoided.

Description

Identity management method and related device for distributed application

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to an identity management method and related device for distributed applications.

Background

With the rapid development of intelligent terminals, the distributed scene of intercommunication and interconnection among different terminal devices is gradually realized, for example, mobile phones, tablet computers, notebook computers, intelligent televisions, routers and the like which are positioned in the same local area network can be interconnected and interconnected. In a distributed scenario, there is a trend to invoke each other, share resources, etc. among Applications (APPs) in different devices.

In a cross-device application access scenario, the capability provided by the accessed application can be called by the application of the local device or by the application on the remote device, in order to manage the access authority of each application, the system allocates an application identity (UID) to each application of the local device to characterize the identity of the application, and if the application of the calling device uses the UID allocated to the application by the local device to access the application in other devices during the cross-device access, the situation that the UIDs of different applications of different devices are the same may exist. For example, application 1 of device a is the same UID as application 2 of device B. When the application 1 of the device a accesses the application 3 of the device B, the device B cannot distinguish whether the application is a native application or a remote device application after obtaining the UID of the application 1, that is, cannot distinguish the application identity of the caller, and the native application and the remote device have different access rights, so that cross-device application access cannot be realized.

Disclosure of Invention

In view of this, the present application provides an identity management method and related device for distributed applications, so as to solve at least part of the above problems, and the disclosed technical solution is as follows:

in a first aspect, the present application provides an identity management method of a distributed application, where the identity management method is applied to a second electronic device, and the second electronic device is connected with a first electronic device through a cross-device interconnection function, where the method includes: receiving a call request which is sent by a first electronic device and used for calling a second application installed by a second electronic device, wherein the call request comprises calling party information, and the calling party information comprises information for identifying the identity of the first electronic device and information for identifying the identity of the first application; in the case that the available distributed application identity (DUID) of the first application does not exist based on the caller information, the first DUID is allocated to the first application; under the condition that the conflict exists between the first DUID and the identification UID of the application program installed on the second electronic equipment, the second DUID is allocated to the first application again; returning the first DUID to the first electronic device under the condition that the first DUID is not in conflict with the UID of the application program installed by the second electronic device, so that the first application calls the second application by using the first DUID; storing the first DUID and application information of the first application to an allocated DUID list, wherein the allocated DUID list comprises the DUIDs allocated by the second electronic device for the distributed application; in the case where it is determined that the number of assigned DUIDs is greater than or equal to the first preset number, the previous second preset number of DUIDs in the list of assigned DUIDs is recovered. It can be seen that in the cross-device call scenario, when the second electronic device determines that the available DUID of the first application does not exist in the second electronic device, the DUID is allocated to the first application. In the process of allocating the DUID for the first application, if the allocated DUID is judged to conflict with the UID of the installed application, a new DUID is allocated for the first application again. In this way, the problem that the identity of the calling party application cannot be confirmed can be avoided, and the effectiveness of distributing the DUID for the distributed application is improved, so that the success rate of calling the application by the cross-equipment is improved. Further, whether the number of the DUIDs exceeds the first preset number is judged, if yes, the preset number of the DUIDs with earlier allocation time is recovered, so that the DUIDs are reallocated to other applications, and the phenomenon that the DUIDs cannot be allocated for new distributed applications due to the fact that the number of the DUIDs is used up is avoided.

In a possible implementation manner of the first aspect, the method further includes: the second electronic equipment installs a third application, and distributes a first UID for the third application; and under the condition that the first UID is determined to have conflict with the third DUID in the allocated DUID list, reallocating the fourth DUID for the distributed application corresponding to the third DUID, and updating the fourth DUID to the allocated DUID list. When the second electronic device installs a new application program, if the UID allocated for the new application program conflicts with the allocated DUID, the new DUID is allocated for the distributed application corresponding to the conflicted DUID again, the availability of the DUID of the distributed application is ensured, and the success rate of cross-device calling is further improved.

In a possible implementation manner of the first aspect, the determining, based on the caller information, that there is no available DUID of the first application includes: searching whether calling party information exists in the allocated DUID list; in the event that there is no caller information in the allocated DUID list, determining that there is no available DUID for the first application; judging whether an application corresponding to the caller information in the allocated DUID list and the first application are the same application or not under the condition that the caller information exists in the allocated DUID list; in the case that it is determined that the application corresponding to the caller information in the allocated DUID list is not the same application as the first application, it is determined that there is no available DUID of the first application. It can be seen that when there is a DUID in the assigned DUID list that matches the application information of the first application, continuing to determine whether the application in the assigned DUID list is the same as the first application, and if not, determining that the DUID in the assigned DUID list is not available. In this way, cross-device calling by using an unavailable DUID can be avoided, so that the accuracy of the identity of the distributed application is improved, and the success rate of the cross-device calling is further improved.

In a possible implementation manner of the first aspect, the caller information includes a device identifier of the first electronic device and an application package name of the first application; searching whether calling party information exists in the allocated DUID list comprises the following steps: searching whether the assigned DUID list has the same DUID information item as the device identification of the first electronic device and the application package name of the first application; determining that caller information exists in the allocated DUID list if the same DUID information item as the device identification of the first electronic device and the application package name of the first application exists in the allocated DUID list; in the case that no item of DUID information that is the same as the device identification of the first electronic device and the application package name of the first application exists in the allocated DUID list, it is determined that no caller information exists in the allocated DUID list.

In a possible implementation manner of the first aspect, the caller information further includes a first application signature of the first application; the determining whether the application corresponding to the DUID matched with the caller information in the allocated DUID list and the first application are the same application includes: comparing whether the second application signature of the application corresponding to the DUID matched with the caller information in the allocated DUID list is the same as the first application signature; when the second application signature is different from the first application signature, determining that the application corresponding to the second application signature is not the same application as the first application; when the second application signature is the same as the first application signature, determining that the application corresponding to the second application signature is the same application as the first application.

In a possible implementation manner of the first aspect, after determining that the application corresponding to the caller information in the allocated DUID list is not the same application as the first application, the method further includes: the DUIDs in the list of assigned DUIDs that match the caller information are reclaimed. Thus, the DUID resources can be recovered in time, and the DUIDs can be allocated for more application programs.

In a possible implementation manner of the first aspect, after determining that the first UID has a conflict with a third DUID in the list of assigned DUIDs, the method further includes: and deleting the third DUID conflicting with the first UID from the assigned DUID list, and marking the third DUID as an invalid DUID. In this way, the distributed application with the DUID conflicting with the UID of the newly installed application can be guaranteed to have the available DUID, and the efficiency and the success rate of cross-device calling of the distributed application are improved.

In a possible implementation manner of the first aspect, the process of determining that the first DUID conflicts with the identity UID of the application installed by the second electronic device includes: searching whether UIDs which are the same as the first DUID exist in an installed application list of the second electronic device, wherein the installed application list comprises UIDs of all applications installed by the second electronic device; when a first DUID exists in the installed application list, determining that the first DUID conflicts with the UID of the installed application of the second electronic device; when the first DUID does not exist in the installed application list, the first DUID is determined not to conflict with the UID of the second electronic device installed application.

In a possible implementation manner of the first aspect, in a case that the number of allocated DUIDs is determined to be greater than or equal to the first preset number, recovering the first second preset number of DUIDs in the allocated DUID list includes: in the event that it is determined that the number of assigned DUIDs is greater than or equal to the first preset number, the first second preset number of DUIDs in the list of assigned DUIDs is re-marked as unassigned.

In a possible implementation manner of the first aspect, in a case that it is determined that the first DUID does not conflict with the UID of the application installed by the second electronic device, after returning the first DUID to the first electronic device, the method further includes: receiving a request of starting a second application from a first electronic device, and sending a first DUID; the first application is determined to have calling rights based on the first DUID, and the second application is started.

In a possible implementation manner of the first aspect, the process of determining that the first UID has a conflict with a third DUID in the list of assigned DUIDs includes: when the third DUID in the assigned DUID list is the same as the first UID, it is determined that the first UID has a collision with the third DUID in the assigned DUID list.

In a possible implementation manner of the first aspect, the method further includes: in the event that it is determined that there is an available DUID for the first application based on the caller information, the available DUID is returned to the first electronic device, such that the first electronic device invokes the second application with the available DUID. In this way, the distributed application can directly use the previously allocated DUID cross-device calling application, thereby improving the utilization rate of the DUID resource.

In a second aspect, an embodiment of the present application provides an electronic device, including: one or more processors, memory, and a touch screen; the memory is used for storing program codes; the processor is configured to execute program code to cause the electronic device to implement the method for identity management of a distributed application according to any one of the first aspects.

In a third aspect, embodiments of the present application further provide a computer-readable storage medium having instructions stored thereon that, when executed on an electronic device, cause the electronic device to perform the method for identity management of a distributed application according to any of the first aspects.

In a fourth aspect, embodiments of the present application also provide a computer program product having instructions stored thereon, which when run on an electronic device, cause the electronic device to implement the method of identity management of a distributed application according to any of the first aspects.

It should be appreciated that the description of technical features, aspects, benefits or similar language in this application does not imply that all of the features and advantages may be realized with any single embodiment. Conversely, it should be understood that the description of features or advantages is intended to include, in at least one embodiment, the particular features, aspects, or advantages. Therefore, the description of technical features, technical solutions or advantageous effects in this specification does not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions and advantageous effects described in the present embodiment may also be combined in any appropriate manner. Those of skill in the art will appreciate that an embodiment may be implemented without one or more particular features, aspects, or benefits of a particular embodiment. In other embodiments, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a distributed system provided in an embodiment of the present application;

fig. 2 is a schematic software architecture diagram of a first device and a second device provided in an embodiment of the present application;

FIG. 3 is a flowchart of a method for identity management of a distributed application according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a distributed application invocation scenario provided in an embodiment of the present application;

FIG. 5 is a flow chart of another method of identity management for a distributed application provided in an embodiment of the present application;

FIG. 6 is a flow chart of a method of identity management for yet another distributed application provided by an embodiment of the present application;

fig. 7 is a flowchart of another method for identity management of a distributed application according to an embodiment of the present application.

Detailed Description

The terms first, second, third and the like in the description and in the claims and drawings are used for distinguishing between different objects and not for limiting the specified sequence.

In the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as examples, illustrations, or descriptions. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

The distributed application refers to an application program installed by a calling device, and for a called device, the calling device installs the application program.

For applications, different access behaviors need to be managed to control rights under different access logics for protection of user data and privacy, application function scope, and the like. When the cross-device application accesses, the target device cannot verify the access authority of the calling application because the calling application does not have a corresponding application package on the target device (i.e., the called device). If the application of the target device is accessed by using the UID of the calling application itself (i.e., the UID allocated by the calling device for the application), the UIDs of the different applications of the different devices may be the same, so when multiple devices are networked together, the UIDs of the applications of the different devices may collide, which requires that the target device allocate a distributed application identity (DUID) to the calling application to control the access rights of the application. Then, if the DUID is not used for a long time after the generation of the DUID, the DUID resource is wasted, or the DUID collides with the UID of the native installed application, so that the cross-device application access authority cannot be checked.

In order to solve the above problem, the present application provides a distributed application identity management method, where a target device may allocate a DUID to a calling application, and reallocate the DUID when the allocated DUID collides with the UID of the native application. Moreover, when the number of the already allocated DUIDs reaches the first preset number, the previously preset number of the DUIDs in the already allocated DUIDs list is recovered, that is, the DUIDs which are unused for a long time are recovered in time. Further, when a new application is installed locally, if the UID allocated for the new installed application conflicts with the DUID already allocated for the distributed application, the DUID is reallocated for the distributed application.

Referring to fig. 1, a schematic diagram of a distributed system according to an embodiment of the present application is shown.

As shown in fig. 1, the distributed system may include devices such as a mobile phone 11, a tablet computer 12, a notebook computer 13, a smart tv 14, a router 15, and a smart speaker 16.

The number of each electronic device may be one or more, and the types of electronic devices in the system are not limited to the above types, and the system may further include other types of electronic devices, such as an in-vehicle device, a smart wearable device (e.g., a smart watch, a smart glasses, etc.), a projector, a Virtual Reality (VR) device, an augmented reality (augmented reality, AR) device, a wireless device in industrial control (industrial control), a wireless device in unmanned (self driving), a wireless device in teleoperation (remote medical surgery), a wireless device in smart grid (smart grid), a wireless device in transportation security (transportation safety), a wireless device in smart city (smart city), a wireless device in smart home (smart home), and the like, which is not limited in this application.

The devices in the distributed system may also be terminal devices in an internet of things (internet of things, ioT) system.

In the system shown in fig. 1, any two devices can be connected in a communication way, and the communication way comprises an internet connection and a near field communication connection. Through the internet connection, the second device may send its supporting application functions to the first device so that the first device discovers and invokes the application functions of the second device. Through near field communication connection, the first device can send a call request to the second device point to point, and the second device can transmit the photographed image to the first device. Near field communication includes bluetooth, wireless fidelity (Wireless Fidelity, WIFI), near field communication (Near Field Communication, NFC), and the like, among others.

In an example, an electronic device may include a processor, an external memory interface, an internal memory, a wireless communication module, a sensor module, a camera, and a display screen.

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

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

The internal memory may be used to store computer-executable program code that includes instructions. The processor executes the instructions stored in the internal memory to perform various functional applications of the electronic device and data processing.

The wireless communication module may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g. wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), bluetooth low energy (Bluetooth Low Energy, BLE), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), short range wireless communication technology (near field communication, NFC), infrared technology (IR), etc. applied on the terminal device. The wireless communication module may be one or more devices that integrate at least one communication processing module.

The sensor module may collect various data of the terminal device, for example, may include a pressure sensor, an acceleration sensor, and the like, and the application does not limit the type of the sensor. The pressure sensor may sense a pressure signal.

The display screen is used for displaying text, images, video, etc.

In addition, on top of the above components, an intelligent operating system is running, for example,the system. Running applications may be installed on the intelligent operating system.

The operating system of the electronic device may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. Embodiments of the present applicationThe software architecture of the system is an exemplary illustration of the software architecture of the terminal device.

Fig. 2 is a software configuration block diagram of an electronic device (a caller device and a target device) of an embodiment of the present application.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the intelligent operating system may be divided into four layers, from top to bottom, an application layer, an application framework layer, a system library, and a kernel layer, respectively.

Fig. 2 (1) is a software architecture diagram of the caller device, and fig. 3 (2) is a software architecture diagram of the target end device (i.e., the called end device).

It should be noted that the software architecture structures of the calling device and the target device are the same, and here, in order to embody the distributed application calling process, the modules used by the calling device and the target device are different, and the modules illustrated by the two devices are slightly different.

The application layer may include a series of application packages. The application package may include applications such as memos, calculators, calls, browsers, and the like.

In the embodiment of the present application, the application layer of the caller device includes a first application, such as a document editing application of notes, memos, WPS, office, etc., and of course, may also include other applications, such as a camera, a phone, etc., which will not be described in detail herein. In this example, as shown in fig. 2 (1), the application program layer includes a first application, and the first application includes a distributed application collaboration service through which cross-device application invocation is implemented. Of course, the application layer may also include other applications,

the target device may include a second application, such as a camera application, which in this example may receive a call from the caller device, initiate the camera application to take an image, and transmit the image back to the caller device.

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

In this example, the application framework layer may include a distributed application framework, a distributed application framework service, for providing a programming interface and programming framework for applications of the application layer to implement distributed application invocation.

In this example, the distributed application framework includes a distributed application context management API for providing an API for distributed application context management and a connection context list for storing distributed context information for connected devices.

The Distributed application framework services include Distributed application services, package management services (PackageManagerService, PMS), distributed package management services (Distributed PackageManagerService, DPMS), and application information databases.

The distributed application service is used to provide a distributed application invocation service.

The package management service is used for providing management of local application programs or services and recording information of the locally installed application programs to an application information database.

DPMS services are used to provide management services for distributed applications (i.e., caller applications).

For example, in this example, the DPMS service includes an application information reading module, a DUID allocation management module, a remote application information recording module, and an application authorization management module.

In the case that the terminal device is used as the target device, information of the calling party application, such as the device ID, the application package name, the application signature and the like of the calling party device, is obtained from the DPMS of the calling party device through the application information reading module.

And the remote application information recording module is used for recording the obtained application information of the distributed application into the application information database.

And the DUID allocation management module is used for realizing the management functions of allocation, invalidation, recovery and the like of the DUID of the calling party application.

And the application authorization management module is used for realizing the authority management of the distributed application.

The application information database is used for storing information of locally installed application programs or distributed applications.

runtimes include core libraries and virtual machines. />runtime is responsible for->Scheduling and management of the system.

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

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

The system library may include a plurality of functional modules. In this example, the system library includes communication services, such asThe intelligent interconnection service (Magic Link) of the system can be used for realizing data transmission among devices, security authentication and account authentication of the same account equipment, self discovery and self networking of the equipment and the like. By way of example, through a communication service, a first device may discover a second device located in the near field and verify the identity of the second device, and after verifying that the second device is a trusted device (i.e., a device that logs into the same user account), transfer a call request, transfer an image, etc., between the first device and the second device.

In addition, the system library may also include Media Libraries (Media Libraries), function Libraries (Function Libraries) graphics processing Libraries (e.g., openGL ES), etc.

The hardware abstraction layer is a layer of abstracted structure between the kernel layer and the Android run. The hardware abstraction layer may be a package for hardware drivers that provides a unified interface for the invocation of upper layer applications. The hardware abstraction layer may include a bluetooth module, a WIFI module, etc. By way of example, the bluetooth module and the WIFI module can shield specific hardware implementation details of the bluetooth driver and the WIFI driver in the kernel layer, and the upper layer application can implement the bluetooth function and the WIFI function by calling the interfaces without knowing a specific implementation manner of the hardware driver of the kernel layer.

The kernel layer is a layer between hardware and software. The kernel layer may include a display driver, a camera driver, an audio driver, a bluetooth driver, a WiFi driver, a universal serial bus (Universal Serial Bus, USB) driver, a central processor driver, and the like.

In some embodiments, a communication service (such as a Magic Link) may perform cross-device connection through related near field communication modules such as a bluetooth driver and a WiFi driver, so as to implement self discovery and ad hoc networking of devices.

The following describes the distributed application identity management method process provided in the embodiment of the present application in detail with reference to the accompanying drawings.

Referring to fig. 3, a flowchart of a distributed application identity management method provided in an embodiment of the present application is shown, where the method is applied to a system including a caller device (i.e., a first device) and a target device (i.e., a second device), and as shown in fig. 3, the method may include the following steps:

s101, the first device and the second device are connected through the intelligent interconnection service.

The first device and the second device are logged in to the same user account, and are interconnected through a MagicLink service. Thereafter, data transfer, application invocation, etc. across devices may be effected between the first device and the second device.

By way of example, a cross-device application access scenario is illustrated by taking a camera application of a mobile phone end called by a note application of a tablet computer as an illustration, and the mobile phone and the tablet computer establish communication connection through intelligent interconnection service (MagicLink).

S102, the first device receives clicking operation of a photographing button in the first application by a user.

The first application may be any application capable of calling the camera APP in the first device, such as a document editing application like notes, memos, WPS, office, etc., or an application like shopping, banking, video clipping, picture processing, social, etc. These applications include corresponding buttons such as a shoot button or a swipe button. The user can click on such a button to invoke the camera APP.

For example, as shown in fig. 4, after the mobile phone and the tablet computer pass through the intelligent interconnection service (MagicLink), the notebook APP installed in the tablet computer may call the camera APP of the mobile phone to take a picture, and store the picture in the currently created note. After the user starts the note APP on the tablet computer and creates a new note, the interface 10 shown in fig. 4 (1) is displayed, and the interface 10 includes a title area 101, a first option area 102, and a second option area 103. For example, the first option area 102 includes options of a manifest, a style, a picture, a recording, and the like. The second option area 103 includes options of photographing 104, handwriting, hyperlinking, forms, importing documents, and the like.

S103, the first device responds to clicking operation of a photographing button to display options of available devices, wherein the available devices are online devices supporting remote application calling.

For example, after the user clicks on the operation of photographing 104 in fig. 4 (1), the interface shown in fig. 4 (2) is displayed, that is, the popup window 201 is displayed at the upper layer of the interface 10, and the popup window 201 is used to display available photographing device options, for example, if the tablet computer is currently connected to the device B, C, D, then the local photographing may be used, or the device B, C or the D photographing may be used.

S104, the first device receives an operation that the user selects the camera APP of the second device to take a picture.

S105, the first device responds to the operation of selecting the camera APP of the second device to take a picture, and initiates a call request of the camera APP of the second device, wherein the call request carries device information and application information of the first device, such as a device ID of the first device and an application package name and an application signature of the first application.

In the example shown in fig. 4, after the user selects the "shoot with device B" option 202, the tablet sends a call request to the mobile phone to call the camera APP in the mobile phone, where the call request carries the device ID of the tablet and the application package name and application signature of the note APP.

The device ID is a feature code for identifying the first device, and may be, for example, a product Serial Number (SN) code of the device, a mobile device identification code (mobile equipment identifier, MEID), an international mobile device identification code (international mobile equipment identity, IMEI), a medium access control (medium access control, MAC) address, or the like.

An application Package Name (Package Name) is a unique identification of an application program, one Package Name representing one application, and the Package Name is used to identify the application.

The main roles of application signatures include: it is checked whether the installation package is modified or not and used to confirm the identity of the signer. The application signature of the same application may be different, for example, the mobile phone installs application a first, uninstalls the application, and reinstalls application a later, in which case the signature of the previously installed application a is different from the signature of the later installed application a.

And S106, the second device responds to the call request to acquire the device ID and application information (such as application package name and application signature) of the calling party.

After receiving a call request of a camera APP in the second device sent by the first device, the second device analyzes the call request to obtain a device ID of the calling device and application information of the calling application.

S107, the second device determines whether the first application is assigned a DUID based on the device ID and the application information of the first device. If not, S108 is performed.

The second device (i.e. the target device) maintains an allocated DUID list, and the list records the DUID information allocated by the second device for the distributed application. For example, the application information database of the device B shown in fig. 2 maintains an assigned DUID list, which records application information of the distributed application connected to the device B, such as including an application package name, an application signature, an assigned DUID for the distributed application, and a device ID of a device to which the distributed application belongs.

For example, whether the allocated DUID list contains the device ID of the first device and the application package name of the first application is searched, and if the allocated DUID list does not contain the device ID of the first device, the first application of the first device cooperates with the second device. If so, it is determined that the second device has assigned a DUID for the first application of the first device, indicating that there is no first collaboration, i.e., no first collaboration service, between the first application of the first device and the second device.

S108, the second device allocates the DUID for the first application of the first device.

For example, the device may reserve a segment of the DUID number assigned to the distributed application, e.g., 18000-19999. The device may assign the DUIDs to the distributed applications in a sequential order.

The second device looks up an unassigned DUID (e.g., a first unassigned DUID) in the distributed application DUID number segment to be assigned to the first application.

S109, the second device judges whether the DUID allocated to the first application conflicts with the UID of the local application. If not, executing S110; if so, the DUID is skipped and the return is made to S108 to reassign the DUID to the first application.

In an exemplary embodiment, application information of the locally installed application program, such as an assigned UID list, is maintained in an application information database of the second device, and the list may include application package names, application signatures, and UIDs assigned to the applications.

In order to avoid that the DUID of the distributed application is identical to the UID of the locally installed application, the second device searches whether the UID identical to the DUID is contained in the assigned UID list after assigning the DUID to the first application, if so, the DUID assigned to the first application is determined to conflict with the UID of the local application, and if not, the DUID assigned to the first application is determined to not conflict with the UID of the local application.

S110, the second device judges whether the number of the allocated DUIDs exceeds a first preset number. If not, S111 is performed, and if so, S112 is performed.

In an example, after determining that the DUID allocated to the first application does not conflict with the UID of the native application, the DUID is recorded in an allocated DUID list, and further, whether the number of allocated DUIDs in the allocated DUID list is greater than or equal to a first preset number is determined, that is, whether the number of all allocated DUIDs exceeds the first preset number is determined.

The first preset number can be set according to practical situations, such as 100.

S111, the second device returns the DUID allocated for the first application to the first device.

If the second device determines that the number of the allocated DUIDs is smaller than the first preset number, the DUIDs allocated for the first application are directly returned to the first device, so that the first device initiates a call request of the second application of the second device by using the DUIDs allocated for the first application.

S112, the second device recovers the first preset number of DUIDs in the assigned DUID list and returns the DUIDs of the first application to the first device.

Illustratively, the information recorded in the assigned DUID list is ordered in the order of early to late time for initializing the distributed context. Reclaiming the assigned DUIDs may be deleting a first predetermined number of DUIDs in the list of assigned DUIDs, which are changed from the assigned state to the unassigned state, i.e., reassigned for use by other applications. The second preset number may be set according to actual requirements, such as 40.

S113, the first device invokes the camera APP of the second device and passes the DUID of the first application.

After the first device receives the DUID allocated to the first application and sent by the second device, the second application (such as a camera APP) of the second device may be invoked, and the DUID of the first application is transferred to the second device, so that the second device verifies the authority of the first application.

S114, the second device determines that the calling party application has calling authority based on the DUID of the first application, and starts the camera APP.

The second device analyzes the call request sent by the first device to obtain the DUID of the first application, the application authorization management module is used for checking the identity and the corresponding authority of the first application, and if the first application is determined to have the authority for calling the camera APP, the camera APP is started.

For example, in the example shown in fig. 4, after the user clicks the photographing option 202 using the device B (in this example, a mobile phone) as shown in fig. 4 (2), the camera APP of the mobile phone is started, that is, the mobile phone displays the photographing interface 300 shown in fig. 4 (3).

S115, the second device transmits the photographed image to the first device.

S116, displaying an image shot by the second device on an interface of the first application of the first device.

For example, in the example shown in fig. 4, after the user clicks the photographing button 301 of the camera APP in the mobile phone, the interface shown in (4) of fig. 4 is displayed, that is, the photographed image is displayed. At the same time, a save button 401 and a return button 402 are displayed. After the user clicks the save button 401, the mobile phone sends the image to the tablet computer, and displays the image on the interface of the current note of the note APP of the tablet computer, such as the image 501 shot by the mobile phone is displayed on the interface 10 shown in (5) of fig. 1.

In addition, when the second device installs the new application program, in order to avoid the UID allocated by the second device for the new installation application from colliding with the DUID allocated for the distributed application, the following steps may be further performed:

s117, the second device installs the new application and assigns the UID to the new application.

S118, the second device determines whether the UID allocated for the newly installed application conflicts with the DUID in the allocated DUID list.

If so, S119 is performed; if not, ending the flow.

In an exemplary embodiment, the DPMS in the second device may register the listening service of the installation application in the PMS, so that when the second device installs the application, the DPMS may learn the UID allocated by the second device for the new installation application, further look up whether the UID is included in the list of allocated DUIDs, if it is determined that the new installation application conflicts with the allocated DUID, and if it is not determined that the new installation application does not conflict with the allocated DUID.

S119, the DUID of the second device, which conflicts with the UID of the newly installed application, is regarded as an invalid DUID, and S108 is executed in a return mode, namely, the new DUID is allocated to the distributed application corresponding to the conflicting DUID again.

If the UID of the newly installed application conflicts with the assigned DUID, the conflicting DUID is skipped (the exemplary DUID may be marked as invalid), a new DUID is reassigned to the distributed application to which the DUID corresponds, and recorded into the assigned DUID list.

According to the distributed application identity management method provided by the embodiment, the target end device can allocate the DUID for the calling party application, and when the allocated DUID conflicts with the UID of the local application, the DUID is reallocated. Moreover, when the number of DUIDs that have been allocated reaches the first preset number, the previous preset number of DUIDs in the DUID list is recovered, that is, the DUIDs that have not been used for a long time are recovered in time. Further, when a new application is installed locally, if the UID allocated for the new installed application conflicts with the DUID already allocated for the distributed application, the DUID is reallocated for the distributed application. The scheme realizes the identity management of the distributed application. Meanwhile, the problem that the distributed application cannot normally call the application of the target end device when the allocated DUID collides with the installation application of the target end device is solved, and the success rate of cross-device call is improved.

Referring to fig. 5, a flowchart of another distributed application identity management method provided in an embodiment of the present application is shown, where the method is applied to a system including a first device (i.e., a caller device) and a second device (i.e., a target device).

In this embodiment, the implementation procedures of S201 to S207 are the same as those of S101 to S107 in the embodiment shown in fig. 3, and will not be repeated here.

In S207, it is determined that the DUID has been assigned to the first application of the first device based on the device ID of the first device and the first application information (of the first application obtained from the first device synchronization), S208 is performed.

S208, the second device acquires the DUID allocated to the first application and the second application information from the allocated DUID list.

The second application information is application information of the first application recorded in the assigned DUID list, including, for example, an application package name, an application signature, and a DUID.

S209, the second device compares whether the application signatures in the first application information and the second application information are consistent; s210 if it is consistent; and if not, S211 is performed consistently.

The application signatures of the same application may be different, thus indicating that the DUID of the first application recorded in the assigned DUID list is not available if the application signature of the first application recorded by the first device is different from the application signature of the first application recorded by the second device.

S210, the second device sends the first device the DUID of the first application found from the list of assigned DUIDs.

If the application signature of the first application recorded in the second device is the same as the application signature of the first application of the first device, the first application recorded in the allocated DUID list is determined to be the same application as the first application of the first device, and further the DUID of the first application in the allocated DUID list is determined to be available and sent to the first device, so that the first device can continue to use the previously allocated DUID to initiate a call request.

S211, the second device recovers the DUID corresponding to the first application in the allocated DUID list, and reallocates a new DUID for the first application of the first device and sends the new DUID to the first device.

If the first application recorded in the assigned DUID list of the second device is different from the application signature of the first application of the first device, it is determined that the first application recorded in the assigned DUID list is not the same application as the first application of the first device, and a new DUID needs to be reassigned to the first application of the first device and returned to the first device. The process of reassigning the DUID to the first application is the same as the process of assigning the DUID to the first application in the embodiment shown in fig. 3 (i.e., S108 to S112), and will not be repeated here.

In addition, the DUID of the first application recorded in the assigned DUID list may be recovered, that is, the information corresponding to the first application recorded in the assigned DUID list may be deleted, so that the deleted DUID may be changed from the assigned state to the unassigned state, and may be continuously assigned to other applications for use.

In addition, S212 to S218 in fig. 5 are the same as the implementation processes of S113 to S119 in the embodiment shown in fig. 3, and are not described here again.

In the distributed application identity management method provided by the embodiment, after receiving a cross-device call request sent by a first device, whether the application of the device is allocated with a DUID is judged first, and if the application is determined to be allocated with the DUID, the previously allocated DUID is obtained. Further, it is determined whether the previously assigned DUID is available, and if so, the previously assigned DUID is continued to be used. If not, the application is reassigned a new DUID. The scheme continues to judge whether the DUID is available or not after determining that the DUID allocated before the first application exists, if so, the method can continue to be used; if the new DUID is unavailable, the new DUID is reassigned, so that the DUID of the first application is ensured to be available, and the success rate of calling the application by the cross-device is improved.

Referring to fig. 6, a flowchart of still another distributed application identity management method provided in an embodiment of the present application is shown, where the method is applied to a target device (i.e., the second device shown in fig. 3 and 5). The steps of the present embodiment, i.e., the steps performed by the second device in the embodiment shown in fig. 3 and 5, are not described in detail.

As shown in fig. 6, the method may include the steps of:

s301, a remote call request of a first application of the first device to a second application of the first device is received.

S302, acquiring the device ID of the first device and first application information, such as an application package name and an application signature.

The first application information is information of a first application stored in the first device.

S303, acquiring an allocated DUID list of the local record.

S304, whether the device ID of the first device and the application package name of the first application exist in the assigned DUID list is searched.

If the assigned DUID list includes the device ID of the first device and the application package name of the first application, it indicates that the second device has assigned the DUID for the first application, and S305 is further executed. If there is no indication that the second device has not assigned a DUID for the first application, further execution proceeds to S309.

S305, second application information of the first application is read from the allocated DUID list.

The second application information includes an application package name, an application signature, and the like of the first application recorded in the assigned DUID list.

S306, comparing whether the application signatures in the first application information and the second application information are consistent.

If so, it is indicated that the first application recorded in the list of assigned DUIDs is the same application as the first application of the first device, i.e. the DUID previously assigned to the first application may also be used further, i.e. execution S307.

If not, it is indicated that the first application recorded in the allocated DUID list is not the same application as the first application of the first device, i.e., the DUID previously allocated to the first application is not available, and S308 is performed.

S307, the authority of the first application is managed by using the DUID allocated for the first application before.

The process of S307 in this embodiment is the same as the process of S114 in the embodiment shown in fig. 3, and will not be described here again.

S308, the DUID allocated for the first application before is recovered, and S309 is continued.

S309, the DUID is allocated for the first application of the first device.

S310, judging whether the currently allocated DUID conflicts with the UID of the local application or not; if so, the DUID is skipped and execution returns to S309. If not, S311 is performed.

S311, judging whether the number of the allocated DUIDs exceeds a first preset number. If yes, executing S313 and then continuing to execute S312; if not, S312 is performed directly.

S312, performing authority management on the first application by using the currently allocated DUID.

S313, recycling the first second preset number of DUIDs in the assigned DUID list.

And S314, installing a new application program and distributing UIDs for the application program.

S315, whether the UID of the newly installed application collides with the DUID in the assigned DUID list; if yes, then S316 is performed; if not, ending the flow.

S316, the DUID conflicting with the UID of the new installation application is regarded as an invalid DUID, and the new DUID is allocated to the distributed application corresponding to the conflicting DUID again.

The implementation process of each step in this embodiment is the same as that of the corresponding steps in the embodiments shown in fig. 3 and 5, and will not be repeated here.

Referring to fig. 7, a flowchart of another method for identity management of a distributed application according to an embodiment of the present application is shown. The method is applied to a system comprising a calling device (i.e. a first device) and a target device (i.e. a second device). As shown in fig. 7, the method may include the steps of:

s401, the first application of the first device receives a call request for the camera APP of the second device. The call request is generated after the first application detects that the user clicks on an operation photographed using the device B as shown in (2) of fig. 4.

S402, the first application responds to the call request, and the distributed context is initialized through the distributed application framework and the distributed application framework service.

S403, the distributed application framework service of the first device obtains a distributed application service registered in a remote service manager (RemoteServiceManager).

The RemoteServiceManager is used to implement the aforementioned intelligent interconnection service (MagicLink), i.e., to implement cross-device component communication. Therefore, the distributed service needs to be registered in the RemoteServiceManager to realize the call of the distributed application, that is, the call of the application across devices.

S404, returning the distributed application service to the distributed application framework service by the remoteServiceManager of the first device through a Binder call.

S405, the distributed application framework service of the first device returns the distributed application service to the distributed application framework.

Through the processes shown in S404 to S405, the RemoteServiceManager returns the distributed application service to the distributed application framework.

S406, the distributed application framework of the first device generates a distributed context of the second device based on the distributed application service.

The distributed context of the second device is used to enable the first device to invoke an application in the second device, i.e. the distributed context is used to initiate invocation of an application within the second device.

And S407, the distributed application framework of the first device transmits the information of the first device to the second device step by step. For example, the information of the first device may include a device ID of the first device, an application package name and an application signature of the first application.

As shown in fig. 7, the distributed application framework of the first device sequentially passes the information of the first device to the RemoteServiceManager of the second device through the distributed application framework service and the RemoteServiceManager. Further, the RemoteServiceManager of the second device communicates information of the first device to the DPMS.

S408, the DPMS of the second device reads the local list of assigned DUIDs.

After the DPMS of the second device receives the information of the first device, the allocated DUID list is read from the application information database of the second device. The assigned DUID list records the DUID assigned by the second device for the distributed application and information of the distributed application, such as a device ID of the device to which the distributed application belongs, an application package name and an application signature of the distributed application, and the like.

S409, the DPMS of the second device determines whether the first application has been assigned a DUID based on the assigned DUID list. If so, S410 is performed. If not, S411 is performed.

The DPMS searches whether the device ID transferred by the first device, the application package name and the application signature of the first application exist in the allocated DUID list. If the assigned DUID list contains the device ID of the first device and the application package name of the first application, the first application is determined to be assigned the DUID. If not, it is determined that the first application has not been assigned a DUID.

S410, the DPMS of the second device judges whether the DUID allocated for the first application is available or not; if yes, then execution S415; if not, S411 is performed.

S411, the DPMS of the second device searches the DUID number segment of the distributed application to allocate the DUID for the first application.

S412, the DPMS of the second device determines whether the DUID allocated by the first application conflicts with the UID of the native application. If it is, skip the DUID and return to S411; if not, S413 is performed.

S413, the DPMS of the second device judges whether the number of the allocated DUIDs exceeds a first preset number; if yes, then S414 is performed; if not, S415 is performed.

S414, the DPMS of the second device recovers the previous second preset number of DUIDs in the list of allocated DUIDs.

The recovered DUID may continue to be assigned to other distributed applications, thereby avoiding the occurrence of a complete exhaustion of the DUID number segments reserved for the distributed applications.

For example, S415 may be continued after S414 is performed, or S415 may be performed after S413 determines that the number of assigned DUIDs exceeds the first preset number, and S414 may be performed. The execution order of S414 and S415 is not limited in the present application.

The implementation process of S409 to S414 in this embodiment is the same as that of S107 to S110 and S112 in fig. 3, and will not be described here again.

And S415, the DPMS of the second device transmits the DUID allocated for the first application to the distributed application framework of the first device step by step.

Illustratively, the DPMS of the second device sends the currently assigned DUID to the RemoteServiceManager of the first device via the RemoteServiceManager of the second device, and the RemoteServiceManager of the first device continues to pass the DUID to the distributed application framework via the distributed application framework service.

S416, the distributed application framework of the first device returns to the first application a distributed application service containing the DUID of the first application.

The distributed application framework of the first device returns the distributed application service to the first application after obtaining the DUID of the first application, writes the DUID of the first application into the distributed application service, and returns the distributed application service to the first application.

S417, the first application initiates a request to pull up the camera activity of the second device through the distributed application service.

This step, i.e. the first application, initiates a call request to call the camera APP of the second device, the call request comprising the DUID of the first application. Camera activity refers to the interface of camera APP.

S418, the distributed application framework of the first device pulls up the camera activity of the second device and delivers the DUID of the first application to the second device.

Illustratively, the distributed application framework of the first device sends a request to pull camera activity to the distributed application framework service, which sends the request to pull camera activity to the RemoteServiceManager through the Binder. The RemoteServiceManager of the first device continues to send a request to pull up camera activity to the RemoteServiceManager of the second device, which sends the request to pull up camera activity to the DPMS of the second device, and passes the DUID of the first application.

S419, after the DPMS of the second device determines that the first application has the authority to call the camera APP through the DUID of the first application, a request for pulling up the camera activity is sent to the AMS.

After the DPMS obtains the request for pulling up the camera activity, judging whether the first application has the authority for calling the camera APP or not based on the DUID of the first application, and if the first application has the authority for calling, further sending the request for pulling up the camera activity to the AMS.

AMS (ActivityManagerService) is the most core service in Android, is located in an application framework layer, is mainly responsible for the work of starting, switching and scheduling four large components in a system, managing and scheduling application processes and the like, and is very important in Android.

S420, the AMS of the second device pulls up the activity of the camera APP, namely, starts the camera APP.

S421, the camera APP of the second device captures an image.

S422, the camera APP of the second device delivers the photographed image layer by layer to the first application of the first device.

As shown in fig. 7, the camera APP returns a photographed image to the AMS, which returns the image to the DPMS. The DPMS sends the shot image to the remoteServiceManager of the first device through the remoteServiceManager of the second device, the remoteServiceManager of the first device returns the image to the distributed application framework service, and the distributed application framework service returns the image to the first application through the distributed application framework, namely the camera APP of the second device sends the shot image to the first application of the first device.

S423, the interface of the first application of the first device displays the image captured by the second device.

In addition, when the second device installs a new application, the DPMS listens to the UID allocated for the new application, and further determines whether the UID collides with the allocated DUID. As shown in fig. 7, the method further comprises the following steps:

s424, the DPMS of the second device registers the listening service of the installation application in the PMS.

The listening service is configured to listen to the behavior of the second device to install the application.

S425, the PMS of the second device installs the new application and batches the UID for the new application.

S426, the DPMS of the second device acquires the UID of the newly installed application from the PMS based on the listening service.

Illustratively, the DPMS of the second device invokes a behavior of a listening service listening to the PMS installation application, the listening service returning the UID of the newly installed application to the DPMS.

S427, the DPMS of the second device determines whether the UID of the newly installed application conflicts with the assigned DUID. If there is a conflict, S428 is performed. If no conflict exists, the current flow is ended.

S428, the DUID that conflicts with the new installed application UID is regarded as an invalid DUID, and the new DUID is reassigned to the distributed application corresponding to the conflicting DUID.

The implementation procedures of S427 to S428 in this embodiment are the same as those of S118 to S119 in fig. 3, and will not be repeated here.

After receiving a distributed application call request initiated by a first application of a first device, a second device determines whether a DUID is allocated to the first application of the first device, and if not, allocates the DUID to the first application. In the process of distributing the DUID for the first application, judging whether the currently distributed DUID conflicts with the UID of the locally installed application, and if not, taking the currently distributed DUID as an application identity of the first application, namely managing the authority of the first application by utilizing the DUID. In addition, in order to avoid that the reserved DUID number segments for the distributed application run out, the DUIDs which are not used for a long time are recovered in time, specifically, whether the total number of the allocated DUIDs exceeds a first preset number is judged after the DUIDs are allocated for the first application, and if the total number of the allocated DUIDs exceeds the first preset number, a second preset number of the DUIDs with the front time stamp is recovered.

Moreover, when the scheme determines that the DUID is allocated to the first application, the scheme further confirms whether the previously allocated DUID is available, if not, the DUID is allocated to the first application again, and if so, the previously allocated DUID is directly multiplexed. The success rate of the distributed application call is improved.

From the foregoing description of the embodiments, it will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of functional modules is illustrated, and in practical application, the above-described functional allocation may be implemented by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to implement all or part of the functions described above. The specific working processes of the above-described systems, devices and units may refer to the corresponding processes in the foregoing method embodiments, which are not described herein.

In the several embodiments provided in this embodiment, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present embodiment may be integrated in one processing unit, each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present embodiment may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in the respective embodiments. And the aforementioned storage medium includes: flash memory, removable hard disk, read-only memory, random access memory, magnetic or optical disk, and the like.

The foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An identity management method of a distributed application, which is characterized by being applied to a second electronic device, wherein the second electronic device is connected with a first electronic device through a cross-device interconnection function, and the method comprises the following steps:

receiving a calling request which is sent by the first electronic equipment and used for calling a second application installed by the second electronic equipment, wherein the calling request comprises calling party information, and the calling party information comprises information for identifying the identity of the first electronic equipment and information for identifying the identity of the first application;

assigning a first DUID for the first application if it is determined that there is no available distributed application identity, DUID, for the first application based on the caller information;

under the condition that the first DUID is determined to conflict with an identification UID of an application program installed on the second electronic equipment, a second DUID is allocated to the first application again;

Returning the first DUID to the first electronic device under the condition that the first DUID is not in conflict with the UID of the application program installed by the second electronic device, so that the first application calls the second application by using the first DUID;

storing the first DUID and the application information of the first application to an allocated DUID list, wherein the allocated DUID list comprises the DUIDs allocated by the second electronic equipment for distributed applications;

and recovering a first second preset number of DUIDs in the assigned DUID list under the condition that the number of the assigned DUIDs is larger than or equal to the first preset number.

2. The method according to claim 1, wherein the method further comprises:

the second electronic equipment installs a third application, and distributes a first UID for the third application;

and under the condition that the first UID is determined to have conflict with a third DUID in the allocated DUID list, reallocating a fourth DUID for the distributed application corresponding to the third DUID, and updating the fourth DUID to the allocated DUID list.

3. The method according to claim 1 or 2, characterized in that the process of determining that there is no available DUID of the first application based on the caller information comprises:

Searching whether the caller information exists in the allocated DUID list;

determining that there is no available DUID for the first application if there is no caller information in the allocated DUID list;

judging whether an application corresponding to the caller information in the allocated DUID list and the first application are the same application or not under the condition that the caller information exists in the allocated DUID list;

in the case that the application corresponding to the caller information in the allocated DUID list is determined not to be the same application as the first application, it is determined that there is no available DUID of the first application.

4. The method of claim 3, wherein the caller information comprises a device identification of the first electronic device and an application package name of the first application;

said looking up whether said caller information is present in said list of assigned DUIDs includes:

searching whether the assigned DUID list has the same DUID information item as the equipment identifier of the first electronic equipment and the application package name of the first application;

determining that the caller information exists in the allocated DUID list if the same DUID information item exists in the allocated DUID list as the device identification of the first electronic device and the application package name of the first application;

And if the assigned DUID list does not contain the same DUID information item as the device identification of the first electronic device and the application package name of the first application, determining that the calling party information does not exist in the assigned DUID list.

5. The method of claim 4, wherein the caller information further comprises a first application signature of the first application;

the step of judging whether the application corresponding to the DUID matched with the caller information in the allocated DUID list and the first application are the same application or not comprises the following steps:

comparing whether a second application signature of the application corresponding to the DUID matched with the caller information in the allocated DUID list is the same as the first application signature;

when the second application signature is different from the first application signature, determining that an application corresponding to the second application signature is not the same application as the first application;

and when the second application signature is the same as the first application signature, determining that the application corresponding to the second application signature is the same application as the first application.

6. A method according to claim 3, wherein after determining that the application corresponding to the caller information in the allocated DUID list is not the same application as the first application, the method further comprises: and recovering the DUID matched with the caller information in the allocated DUID list.

7. The method of claim 2, wherein after determining that the first UID has a collision with a third DUID in the list of assigned DUIDs, the method further comprises:

and deleting a third DUID conflicting with the first UID from the allocated DUID list, and marking the third DUID as an invalid DUID.

8. The method according to any one of claims 1-5, wherein the process of determining that the first DUID conflicts with an identification, UID, of an application installed by the second electronic device comprises:

searching whether UIDs which are the same as the first DUID exist in an installed application list of the second electronic device, wherein the installed application list comprises UIDs of all applications installed by the second electronic device;

determining that the first DUID conflicts with a UID of the second electronic device installed application when the first DUID exists in the installed application list;

and when the first DUID does not exist in the installed application list, determining that the first DUID does not conflict with the UID of the second electronic equipment installed application.

9. The method according to any one of claims 1-8, wherein, in the case where it is determined that the number of allocated DUIDs is greater than or equal to a first preset number, recovering a first second preset number of DUIDs in the list of allocated DUIDs, comprises:

And in the case that the number of the allocated DUIDs is larger than or equal to the first preset number, re-marking the first second preset number of the DUIDs in the allocated DUID list as unallocated DUIDs.

10. The method of any of claims 1-9, wherein, upon determining that the first DUID does not conflict with a UID of an application installed by the second electronic device, the method further comprises, after returning the first DUID to the first electronic device:

receiving a request of the first electronic equipment for starting the second application, and sending the first DUID;

and determining that the first application has calling authority based on the first DUID, and starting the second application.

11. The method of any of claims 2-10, wherein determining that the first UID has a collision with a third DUID in the list of assigned DUIDs comprises:

when a third DUID in the assigned DUID list is the same as the first UID, determining that the first UID has a collision with the third DUID in the assigned DUID list.

12. The method according to any one of claims 1-11, further comprising: and in the case that the available DUID of the first application exists based on the caller information, returning the available DUID to the first electronic device, so that the first electronic device invokes the second application by adopting the available DUID.

13. An electronic device, the electronic device comprising: one or more processors, memory, and a touch screen; the memory is used for storing program codes; the processor is configured to run the program code to cause the electronic device to implement the identity management method of the distributed application as claimed in any one of claims 1 to 12.

14. A computer readable storage medium having instructions stored thereon which, when executed on an electronic device, cause the electronic device to perform the method of identity management of a distributed application as claimed in any of claims 1 to 12.