A file sharing method, device and storage medium

Abstract

The disclosed embodiment discloses a file sharing method, device and storage medium, the method is applied to a first electronic device, a first application and a second application are installed in the first electronic device, the method comprises: a software development kit SDK integrated with the second application receives a call request of the first application; wherein the call request comprises: a file path; the SDK passes the file path to an open function of the second application, wherein the file path is used for the open function to open a private file in the memory space of the first electronic device; the SDK returns the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file. In this way, the first application can access the private file of the second application, and the first application shares the private file of the second application.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a file sharing method, device and storage medium. Background Art

[0002] When an application (APP) is installed on a terminal device, some files of the application will be placed in the private file directory of the application. Only the application has access to the private files in its private file directory, and other applications cannot access these private files. Summary of the invention

[0003] Embodiments of the present disclosure provide a file sharing method, device, and storage medium.

[0004] According to a first aspect of an embodiment of the present disclosure, there is provided a file sharing method, which is applied to a first electronic device, wherein a first application and a second application are installed in the first electronic device, and the method includes:

[0005] The software development kit SDK integrated with the second application receives a call request of the first application; wherein the call request includes: a file path;

[0006] The SDK passes the file path to the open function of the second application, wherein the file path is used for the open function to open the private file in the memory space of the first electronic device;

[0007] The SDK returns the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file.

[0008] In some embodiments, the SDK returns the file information of the private file opened in the memory space to the first application, including:

[0009] The SDK obtains a file descriptor generated after the private file is opened in the memory space;

[0010] The file descriptor is sent to the first application.

[0011] In some embodiments, the method further comprises:

[0012] Determining, according to the calling request, an operation type of the first application operating the private file;

[0013] The SDK passes the file path to the opening function of the second application, including:

[0014] When the operation type is a read operation, the file path is passed to an open function of the second application.

[0015] In some embodiments, the method further comprises:

[0016] When the operation type is a write operation, the SDK passes the file path to a creation function of the second application, wherein the creation function is used to create a first file in a file directory of the second application according to the file path;

[0017] The SDK passes the file path to the opening function of the second application, including:

[0018] After the creation function completes the creation of the first file, the SDK passes the file path of the first file to the opening function of the second application.

[0019] In some embodiments, the method further comprises:

[0020] When the operation type is an update operation, the SDK passes the file path to a delete function of the second application, wherein the delete function is used to delete the second file of the second application according to the file path;

[0021] The SDK passes the file path to the creation function of the second application, wherein the creation function is used to create a third file with the same name as the second file in the file directory of the second application according to the file path after the second file is deleted;

[0022] The SDK passes the file path to the opening function of the second application, including:

[0023] After the creation function completes the creation of the third file, the SDK passes the file path of the third file to the opening function of the second application.

[0024] In some embodiments, sending the file descriptor to the first application includes:

[0025] The SDK sends the file information to the first application through a preset inter-process communication mechanism.

[0026] In some embodiments, the method further comprises:

[0027] Performing identity verification on the first application according to the calling request;

[0028] The SDK passes the file path to the opening function of the second application, including:

[0029] After the identity verification of the first application is passed, the file path is passed to the open function of the second application.

[0030] In some embodiments, the calling request carries an application identifier of the first application, and the performing identity verification on the first application according to the calling request includes:

[0031] The SDK obtains the package name and signature information of the first application according to the application identifier;

[0032] The identity of the first application is verified according to the obtained package name and signature information.

[0033] According to a second aspect of an embodiment of the present disclosure, there is provided a file sharing method, which is applied to a first electronic device, wherein a first application and a second application are installed in the first electronic device, and the method includes:

[0034] The first application sends a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application;

[0035] The first application receives the file information returned by the SDK; the file information is generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device;

[0036] The first application processes the private file in the memory space according to the file information.

[0037] In some embodiments, the first application processes the private file in the memory space according to the file information, including at least one of the following:

[0038] When the operation type associated with the call request is a read operation, reading the private file from the memory space according to the file information;

[0039] When the operation type associated with the call request is a write operation, writing content to the first file opened in the memory space according to the file information; the first file is: a private file created by the SDK calling the creation function of the second application;

[0040] When the operation type associated with the calling request is an update operation, content is written to the third file opened in the memory space according to the file information; the third file is: a private file created by the SDK after calling the delete function of the second application to delete the second file with the same name as the third file and calling the create function.

[0041] In some embodiments, the method further comprises:

[0042] The first application receives the file content and the file path sent by the second electronic device; wherein the file content is used for the first application to write the private file of the second application according to the file path;

[0043] or,

[0044] The file path is determined according to an input operation of the user interface UI.

[0045] In some embodiments, the method further comprises:

[0046] The first application sends the read file content of the private file of the second application and the file path of the private file in the file directory of the second application to the third electronic device.

[0047] According to a third aspect of an embodiment of the present disclosure, there is provided a file sharing device, which is applied to a first electronic device, wherein a first application and a second application are installed in the first electronic device, and the device includes:

[0048] A receiving module, a software development kit SDK for integrating the second application, receives a call request of the first application; wherein the call request includes: a file path;

[0049] A first transfer module, configured for the SDK to transfer the file path to an open function of the second application, wherein the file path is used by the open function to open a private file in a memory space of the first electronic device;

[0050] The sending module is used for the SDK to return the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file.

[0051] According to a fourth aspect of an embodiment of the present disclosure, a file sharing device is provided, wherein a first application and a second application are installed in a first electronic device, and the device includes:

[0052] A first sending module, configured for the first application to send a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application;

[0053] A first receiving module, configured for the first application to receive file information returned by the SDK; the file information is generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device;

[0054] A processing module is used for the first application to process the private file in the memory space according to the file information.

[0055] According to a fifth aspect of an embodiment of the present disclosure, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the file sharing method described in any one of the first aspects when executing the program; or, the processor implements the steps of the file sharing method described in any one of the second aspects when executing the program.

[0056] According to a sixth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the file sharing method described in any one of the first aspects are implemented; or, when the computer program is executed by a processor, the steps of the file sharing method described in any one of the second aspects are implemented.

[0057] The disclosed embodiment discloses a file sharing method, device and storage medium. The method is applied to a first electronic device, in which a first application and a second application are installed. The SDK integrated by the second application receives a call request of the first application, and passes the file path in the call request to the open function of the second application. Since the SDK is integrated in the second application, when the SDK passes the file path to the open function of the second application to open the private file of the second application, it is equivalent to the second application itself opening the private file, so the private file of the second application can be opened. Since the SDK returns the file information of the opened private file to the first application, it will not be leaked to other applications, thus ensuring the security of the private file of the second application. Moreover, since the SDK returns the file information of the opened private file to the first application, the first application does not need to call the open function of the second application to open the private file, thus bypassing the permission check of the second application on the first application, and the first application can directly use the file information of the private file returned by the SDK to operate the content of the private file. In this way, the first application can access the private file of the second application, and the first application can share the private file of the second application.

[0058] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0060] Figure 1It is a flowchart of a file sharing method shown in an embodiment of the present disclosure;

[0061] Figure 2 yes Figure 1 The flowchart of step 103 is shown;

[0062] Figure 3 is a flowchart of another file sharing method shown in an embodiment of the present disclosure;

[0063] Figure 4 is a system architecture diagram of a file sharing system shown in an embodiment of the present disclosure;

[0064] Figure 5 It is a specific flow chart of a file sharing method shown in an embodiment of the present disclosure;

[0065] Figure 6 is a block diagram of a file sharing device shown in an embodiment of the present disclosure;

[0066] Figure 7 is a block diagram of another file sharing device shown in an embodiment of the present disclosure;

[0067] Figure 8 It is a structural block diagram of a computer device shown in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solutions and advantages of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure. In the absence of conflict, the embodiments in the present disclosure and the features in the embodiments can be arbitrarily combined with each other. The steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions. In addition, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that here.

[0069] It can be understood that the description of various embodiments in the present disclosure focuses on the differences between the various embodiments, and the same or similar aspects thereof can be referenced to each other, and for the sake of brevity, they will not be described one by one.

[0070] It should be noted that: "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0071] Figure 1is a flowchart of a file sharing method shown in an embodiment of the present disclosure. The method is applied to a first electronic device. The first electronic device has a first application and a second application installed therein. Figure 1 As shown, the method comprises the following steps:

[0072] 101. A software development kit SDK integrated with a second application receives a call request from a first application; wherein the call request includes: a file path.

[0073] In the embodiment of the present disclosure, the file sharing method is applied to a first electronic device, which may be a smart phone, a tablet computer, a personal computer (PC), or a vehicle-mounted device. The operating system of the first electronic device may be an Android system, an iOS system, or other operating systems that can implement the disclosed solution. It is understood that the present embodiment does not specifically limit the type of the first electronic device and the operating system it carries.

[0074] The first application and the second application are different applications. For example, the first application may be a file transfer application, or other applications that can be used to transfer files, such as email, RCS (Rich Communication Services & Suite) applications. The second application may be a third-party application, where the third application refers to a third-party application developed by a third-party developer. The second application may be a game-type application, an entertainment-type application, and the like. Among them, game-type applications may include action games, adventure games, simulation games, role-playing games, and the like. Entertainment-type applications may include short videos, long videos, news, and the like.

[0075] The second application is pre-integrated with a software development kit (SDK), which may be provided by the provider of the first application and embedded into the second application by the provider of the second application. The SDK includes several abstracted application programming interfaces (APIs), and the first application can call the internal logic of the SDK through the APIs provided by the SDK to perform corresponding operations.

[0076] The call request may be a request sent by the first application to call the SDK. For example, the call request may represent: the first application requests to call the SDK to read the private file of the second application, or the first application requests to call the SDK to write content to the private file of the second application, or the first application requests to call the SDK to update the content of the private file of the second application, etc.

[0077] The call request includes a file path, and different file paths may correspond to different files. The file path may be used to determine the storage location of the private file to be shared in the memory space of the first electronic device. The private file to be shared is located in the private directory of the second application, for example, " / data / data / <Package Name> / " directory. The private file can be a resource file of the second application, such as various pictures, audio, video and other resource files.

[0078] Here, the file path may be: a file path determined by the first application according to an input operation of the user interface UI. For example, the input operation may be: a selection operation of a private file by a user or an entry operation of a file path of a private file by a user.

[0079] Alternatively, the file path may be: the first application of the first electronic device as the receiving end receives the file path sent by other electronic devices (for example, the second electronic device) as the sending end. Here, the first application of the first electronic device as the receiving end not only receives the file path sent by the other electronic devices, but also receives the file content sent by the other electronic devices, wherein the file content can be used for the first application of the first electronic device to write the private file of the second application according to the file path.

[0080] Specifically, the SDK integrated by the second application receives the calling request of the first application through a predefined interface to obtain the file path in the calling request.

[0081] 102. The SDK passes the file path to the open function of the second application, wherein the file path is used by the open function to open the private file in the memory space of the first electronic device.

[0082] The opening function of the second application is used for the SDK to call to open the file of the second application.

[0083] The file path is: a storage path of a target file that the first application needs to access in the first electronic device.

[0084] In the disclosed embodiment, the SDK can call the open function of the second application according to the call address of the open function of the second application, and pass the file path to the open function of the second application, so that the open function can open the private file of the second application in the memory space of the first electronic device according to the file path. After the open function of the second application opens the private file of the second application in the memory space of the first electronic device, the file information of the opened private file is generated.

[0085] 103. The SDK returns the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file.

[0086] In the disclosed embodiment, after acquiring the file information of the opened private file, the SDK returns the file information of the private file to the first application, so that the first application can operate the opened private file according to the file information.

[0087] The file information of the private file may be file information of the private file that can be accessed by the first application after the private file is opened, for example, the storage address of the private file in the memory space, etc. Exemplarily, the file information may be a file descriptor.

[0088] It is worth noting that when the call request includes multiple file paths (that is, there are multiple private files that need to be shared), the SDK needs to pass each file path to the open function of the second application in turn, so that the open function will open the private files corresponding to the file path in turn. Accordingly, the SDK will return the file information of each private file opened in the memory space to the first application.

[0089] In the disclosed embodiment, the SDK integrated by the second application receives the call request of the first application, and passes the file path in the call request to the open function of the second application. Since the SDK is integrated in the second application, when the SDK passes the file path to the open function of the second application to open the private file of the second application, it is equivalent to the second application itself opening the private file, so the private file of the second application can be opened. Since the SDK returns the file information of the opened private file to the first application and will not be leaked to other applications, the security of the private file of the second application is guaranteed. In addition, since the SDK returns the file information of the opened private file to the first application, the first application does not need to call the open function of the second application to open the private file, thus bypassing the second application's permission check on the first application, and the first application can directly use the file information of the private file returned by the SDK to operate the content of the private file. In this way, the first application can access the private file of the second application, and the first application can share the private file of the second application.

[0090] In some embodiments, the method may further include:

[0091] Determine, according to the call request, an operation type of the first application operating the private file;

[0092] The call request may be used to determine the operation type, and the file operation type may be divided into: read operation, write operation and update operation according to different file operation modes.

[0093] For example, the call request includes: an operation instruction for a file operation, which may be generated according to a user instruction. The operation type may be determined according to the operation instruction.

[0094] In the above step 102, the SDK passes the file path to the opening function of the second application, which may include:

[0095] When the operation type is a read operation, the file path is passed to the open function of the second application.

[0096] In the disclosed embodiment, when it is determined that the operation type of the first application operating a private file is a read operation, it indicates that the first application needs to read the private file from the file directory of the second application. At this time, the SDK will directly pass the file path in the call request to the open function of the second application, so that the open function can open the private file corresponding to the file path in the file directory of the second application, and then generate file information of the opened private file that can be returned by the SDK to the first application.

[0097] In some embodiments, the method may further include:

[0098] When the operation type is a write operation, the SDK passes the file path to a creation function of the second application, wherein the creation function is used to create the first file in a file directory of the second application according to the file path.

[0099] In the above step 102, the SDK passes the file path to the open function of the second application, including:

[0100] After the creation function completes the creation of the first file, the SDK passes the file path of the first file to the opening function of the second application.

[0101] In the disclosed embodiment, when it is determined that the operation type of the first application operating a private file is a write operation, it indicates that the first application needs to write a private file to the file directory of the second application. At this time, the SDK will first pass the file path in the call request to the creation function of the second application, so that the creation function can create a first file with empty file content corresponding to the file path in the file directory of the second application. After the first file is created, the SDK passes the file path of the first file to the open function of the second application, so that the open function can open the first file, and then generate file information of the opened first file that can be returned by the SDK to the first application.

[0102] In some embodiments, the method may further include:

[0103] When the operation type is an update operation, the SDK passes the file path to a delete function of the second application, wherein the delete function is used to delete the second file of the second application according to the file path;

[0104] The SDK passes the file path to the creation function of the second application, wherein the creation function is used to create a third file with the same name as the second file in the file directory of the second application according to the file path after the second file is deleted;

[0105] In the above step 102, the SDK passes the file path to the opening function of the second application, which may include:

[0106] After the creation function completes the creation of the third file, the SDK passes the file path of the third file to the opening function of the second application.

[0107] In the disclosed embodiment, when it is determined that the operation type of the first application operating the private file is an update operation, it indicates that the first application needs to update the private file in the file directory of the second application. At this time, the SDK will first pass the file path in the call request to the delete function of the second application, so that the delete function can delete the second file corresponding to the file path in the file directory of the second application (here, the file content of the second file is not empty). After the second file corresponding to the file path is deleted, the SDK passes the file path to the create function of the second application, so that the create function can create a third file with empty file content corresponding to the file path in the file directory of the second application, wherein the second file has the same file name as the third file. After the third file is created, the SDK passes the file path of the third file to the open function of the second application, so that the open function can open the third file, and then generate file information of the opened third file that can be returned by the SDK to the first application.

[0108] In some embodiments, Figure 2As shown, in the above step 103, the SDK returns the file information of the private file whose memory space is opened to the first application, which may include:

[0109] 1031, SDK obtains the file descriptor generated after the private file is opened in the memory space;

[0110] 1032, send the file descriptor to the first application.

[0111] Here, the file descriptor corresponds to the opened private file. The file descriptor is a non-negative integer in form, and the file descriptor can be used as an index value, which points to the record table of the open files of each process maintained by the system kernel.

[0112] In some embodiments, sending the file descriptor to the first application may include:

[0113] The SDK sends the file information to the first application through a preset inter-process communication mechanism.

[0114] The preset inter-process communication mechanism may be a cross-process communication mechanism, such as a Binder mechanism.

[0115] In the disclosed embodiment, the file descriptor generated after the private file is opened in the memory space is sent to the first application through the SDK, so that the first application can use the file descriptor to perform corresponding operations on the opened private file, such as the first application reading the opened private file, or the first application writing content to the opened private file, or the first application updating the content of the opened private file.

[0116] In some embodiments, the method may further include:

[0117] According to the calling request, the identity of the first application is verified.

[0118] In an embodiment of the present disclosure, when receiving a call request, the SDK can authenticate the first application that sends the call request. When the identity authentication of the first application is successful, the SDK allows the first application to call it; when the identity authentication of the first application is failed, the SDK refuses to be called by the first application.

[0119] In the above step 102, the SDK passes the file path to the opening function of the second application, which may include:

[0120] After the identity verification of the first application is passed, the file path is passed to the open function of the second application.

[0121] In the disclosed embodiment, after the identity verification of the first application is passed, the SDK passes the file path to the open function of the second application. In this way, the private files of the second application can be prevented from being illegally accessed, thereby effectively ensuring the security of the private files of the second application.

[0122] In some embodiments, the call request carries an application identifier of the first application, and performing identity verification on the first application according to the call request may include:

[0123] The SDK obtains the package name and signature information of the first application according to the application identifier;

[0124] The identity of the first application is verified according to the obtained package name and signature information.

[0125] The application identifier (UID) of the first application is used to identify the first application, and the application identifier is allocated to the first application when the first application is installed on the first electronic device.

[0126] The package name is the name of the installation package of the first application, and the signature information is the signature of the entire application file by the provider of the first application using its own private key to prevent the first application from being counterfeited or tampered with.

[0127] The identity verification of the first application according to the obtained package name and signature information may include:

[0128] Specifically, it can be determined whether the obtained package name and signature information are included in the preset whitelist. If both are package names, and the package name and signature information point to the same application in the whitelist, the identity authentication result of the first application is determined to be passed. Otherwise, the identity authentication result of the first application is determined to be failed. Here, the preset whitelist stores the package names and signature information of the applications that are allowed to call the SDK.

[0129] Among them, the preset whitelist can be provided to the SDK by the second application, for example, the whitelist information obtained by the second application from the server of the second application. Exemplarily, in order to realize file sharing between applications, the server of the second application can pre-store the package name and signature information of the application program that is allowed to call the SDK in the whitelist, and send it to the second application, so that the second application can provide it to its integrated SDK. It is understandable that the second application can update the package name and signature information of the application program in the whitelist in real time through interaction with the server of the second application.

[0130] In the disclosed embodiment, the SDK performs identity verification on the first application according to the package name and signature information of the first application, thereby improving the security of the private files of the second application.

[0131] In some embodiments, considering security, in order to reduce the risk of the SDK being used by unauthorized third-party applications, the SDK may include a preset application whitelist, which includes attribute information of applications that are allowed to integrate the SDK. Among them, the attribute information of applications that are allowed to integrate the SDK may include: one or more of name information, function information, and signature information. In this way, when the second application needs to integrate the SDK, the SDK can match the attribute information of the second application in the preset application whitelist, and when the match is successful, it is determined to allow the second application to integrate the SDK.

[0132] In other embodiments, when the SDK is integrated and installed on a second application, the second application sends information about the SDK to the server of the second application. After receiving an installation confirmation indication returned by the server of the second application, the first electronic device can successfully integrate and install the SDK into the second application, thereby ensuring the security of SDK use with authorization by the server of the second application.

[0133] Figure 3 is a flowchart of another file sharing method shown in an embodiment of the present disclosure, the method is applied to a first electronic device, the first electronic device has a first application and a second application installed therein, such as Figure 3 As shown, the method comprises the following specific steps:

[0134] 301. The first application sends a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application.

[0135] Specifically, the implementation process of step 301 may refer to step 101 in the above method embodiment, which will not be repeated here.

[0136] 302, the first application receives the file information returned by the SDK; the file information is: generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device.

[0137] Specifically, the first application receives the file information returned by the SDK through a preset inter-process communication mechanism, where the preset inter-process communication mechanism may be a cross-process communication mechanism, such as a Binder mechanism.

[0138] 303. The first application processes the private file in the memory space according to the file information.

[0139] Here, the file information may be a file descriptor.

[0140] Specifically, the first application may use the file descriptor to perform corresponding operations on the opened private file, such as the first application reading the opened private file, or the first application writing content to the opened private file, or the first application updating the content of the opened private file.

[0141] In the disclosed embodiment, the first application sends a call request to the SDK integrated with the second application, and the call request includes the file path of the private file of the second application. The first application receives the file information returned by the SDK. The file information is generated after the SDK calls the open function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device. Since the SDK is integrated in the second application, when the SDK passes the file path to the open function of the second application to open the private file of the second application, it is equivalent to the second application using its own access rights to open the private file, so the private file of the second application can be opened. After the SDK returns the file information of the opened private file to the first application, the first application does not need to call the open function of the second application to open the private file, thus bypassing the permission check of the second application on the first application, and the first application can directly use the file information of the private file returned by the SDK to process the private file of the second application. In this way, the first application can access the private file of the second application, and the first application can share the private file of the second application.

[0142] In some embodiments, in the above step 301, the first application processes the private file in the memory space according to the file information, which may include at least one of the following:

[0143] When the operation type associated with the call request is a read operation, the private file is read from the memory space according to the file information;

[0144] When the operation type associated with the call request is a write operation, write content to the first file opened in the memory space according to the file information; the first file is: a private file created by the SDK calling the creation function of the second application;

[0145] When the operation type associated with the call request is an update operation, the content is written to the third file opened in the memory space according to the file information; the third file is: the SDK calls the delete function of the second application to delete the second file with the same name as the third file and calls the create function to create a private file.

[0146] Among them, according to different file operation modes, the operation types associated with the call request can be divided into: read operation, write operation and update operation.

[0147] In the disclosed embodiment, the first application performs corresponding operations on the private files in the memory space of the first electronic device according to the file information returned by the SDK and in combination with the operation type of the file, thereby enabling the first application to share the private files of the second application.

[0148] In some embodiments, the method may further include:

[0149] The first application receives the file content and the file path sent by the second electronic device; wherein the file content is used for the first application to write the private file of the second application according to the file path;

[0150] Alternatively, the file path is determined according to an input operation of the user interface UI.

[0151] The second electronic device may be a smart phone, a tablet computer, a personal computer, or a vehicle-mounted device. The operating system of the first electronic device may be an Android system, an iOS system, or other operating systems that can implement the disclosed solution. The second electronic device and the first electronic device are equipped with the same operating system, for example, the operating system of the first electronic device and the operating system of the second electronic device are both Android systems.

[0152] Here, the user interface UI is the user interface of the first electronic device. The input operation may be: a selection operation of the user on the user interface of the first electronic device for the private file or an input operation for the file path of the private file.

[0153] Exemplarily, a file transfer application is used as the first application, and a game application is used as the second application.

[0154] For example, when a game application in a first electronic device needs to share resource files of a game application in a second electronic device, or the resource files of the game application in the first electronic device need to be updated (for example, resource upgrade), the file transfer application in the first electronic device can receive the file content and file path sent by the second electronic device, and send a call request containing the file path to the SDK integrated with the game application in the first electronic device, so as to request the SDK to write the file content to the resource files of the game application, or request the SDK to update the content of the resource files of the game application.

[0155] The file content received from the second electronic device is shared with the game application in the first electronic device through the file transfer application in the first electronic device, thereby greatly saving the cost of the first electronic device re-downloading the resource files of the game application through the network.

[0156] For another example, when the resource files of a game application in a first electronic device need to be shared with a game application in a second electronic device, the file transfer application in the first electronic device can determine the file path based on the input operation of the user interface UI, and send a call request containing the file path to the SDK integrated with the game application in the first electronic device, requesting to call the SDK to read the resource files of the game application.

[0157] The file transfer application in the first electronic device can read the resource files of the game application in the first electronic device, so that the file transfer application can share the read resource files of the game application with game applications in other electronic devices, thereby greatly saving the cost of other electronic devices re-downloading the resource files of the game application through the network.

[0158] In some embodiments, the method may further include:

[0159] The first application sends the read file content of the private file of the second application and the file path of the private file in the file directory of the second application to the third electronic device.

[0160] The third electronic device may be a smart phone, a tablet computer, a personal computer, or a vehicle-mounted device. The operating system of the first electronic device may be an Android system, an iOS system, or other operating systems that can implement the disclosed solution. The third electronic device has the same operating system as the first electronic device, for example, the operating system of the first electronic device and the operating system of the third electronic device are both Android systems.

[0161] In the disclosed embodiment, the first application sends the file content of the read private file of the second application and the file path of the private file in the file directory of the second application to the third electronic device, thereby greatly saving the cost of the third electronic device to re-download the resource file through the network.

[0162] A specific example is provided below in combination with any of the above embodiments.

[0163] Play Asset Delivery is a new way of publishing game APK (Android application package) defined by Google. If the game APK is published to Google Play using Play Asset Delivery, after the user downloads and installs the game app in Google Play, the resource files of the game app will be placed in the private directory of the game app and cannot be accessed by other apps.

[0164] SHAREit is a tool that can transfer files end-to-end for users. The premise of SHAREit to transfer files end-to-end is that you need to have permission to read the files. However, after the game APK is released using Play Asset Delivery, the resource files of the game application are placed in its private directory, and SHAREit cannot read the resource files of the game application.

[0165] In order to solve the problem that SHAREit cannot read the game APK resource files, an SDK is integrated into the game application. With this SDK, the game application can establish communication with SHAREit, and the game application can share its resource files with SHAREit. With the help of SHAREit's transmission capabilities, end-to-end file sharing is achieved. Users can save the cost of re-downloading resource files through the network.

[0166] Figure 4 is a system architecture diagram of a file sharing system shown in an embodiment of the present disclosure. Figure 4 As shown, the system includes a sending end and a receiving end, wherein both the sending end and the receiving end include but are not limited to: a smart phone, a tablet computer, a personal computer or a vehicle-mounted device, etc. A file transfer application and a third-party application (for example, a game application) are installed on both the sending end and the receiving end, and an SDK that can be called by the file transfer application is integrated in the third-party application. On the sending end side, the file transfer application reads the private data packet of the third-party application by calling the SDK integrated with the third-party application, and transmits the private data packet to the receiving end. On the receiving end side, the file transfer application writes the private data packet received from the sending end side into the private file of the third-party application by calling the SDK integrated with the third-party application, thereby realizing end-to-end sharing of files.

[0167] Figure 5 is a specific flow chart of a file sharing method shown in an embodiment of the present disclosure. Figure 5 As shown, both the sending end and the receiving end are deployed with a file transfer application and a third-party application, and the process of the file sharing method may include:

[0168] S1: The file transfer application on the sending end initiates a request to the file transfer application on the receiving end to request to establish a connection.

[0169] S2: After receiving the request confirmation response from the receiving end, the file transfer application on the sending end establishes a communication connection with the file transfer application on the receiving end.

[0170] S3: The file transfer application on the sending end calls the SDK predefined interface integrated into the third-party application, calls the internal logic of the SDK, and requests to read the private file.

[0171] When the internal logic of the SDK is executed, it will obtain the UID of the file transfer application through the Binder mechanism, and then obtain the package name of the file transfer application, and then obtain the signature information through the package name of the file transfer application. After obtaining the signature information, the identity of the file transfer application will be verified. If the file transfer application fails the verification, the file reading operation will not continue.

[0172] S4: On the sending end side, if the SDK integrated by the third-party application determines that the file transfer application passes the identity verification, it opens the private file to be shared and returns the file descriptor of the opened private file to the file transfer application.

[0173] Among them, if the file transfer application on the sending side passes the identity verification, the SDK will call the open function to pass in the path of the file to be opened, and open the private file to be shared. At this time, it can be regarded as a third-party application opening its own file, so it has permission. When the SDK calls the open function and passes in the path of the file to be opened, it can open the private file and obtain the file descriptor corresponding to the private file. After obtaining the file descriptor, it will be passed to the file transfer application through the Binder mechanism, where the Binder mechanism itself has the ability to pass file descriptors. In this way, the third-party application will accurately pass the file descriptor to the file transfer application without leaking it to other applications, ensuring the security of private files.

[0174] By returning the file descriptor of the private file to the file transfer application, after the file transfer application on the sending side obtains the file descriptor, the file transfer application on the sending side can directly use this file descriptor to access the content of the private file of the third-party application on the sending side, without having to call the open function again to open the file, thus bypassing the permission check.

[0175] S5: After obtaining the file descriptor, the file transfer application on the sending end sends the file path corresponding to the private file to the file transfer application on the receiving end, and sends a first notification message to notify the file transfer application on the receiving end that there is a file to be transferred.

[0176] S6: The file transfer application on the receiving end sends the file path to the SDK integrated with the third-party application and forwards the first notification message.

[0177] S7: The SDK integrated by the third-party application on the receiving end creates an empty file according to the file path and opens the empty file in a writable mode.

[0178] Among them, on the receiving side, the file transfer application calls the third-party application through the SDK interface, and then passes the file path to the SDK; the internal logic of the SDK will create an empty file according to the file path, and then open the empty file in writable mode by calling the open function, obtain the file descriptor of the opened empty file, and then return the file descriptor to the file transfer application.

[0179] S8: The SDK integrated by the third-party application on the receiving end returns the file descriptor corresponding to the opened empty file to the file transfer application.

[0180] S9: After obtaining the file descriptor corresponding to the opened empty file, the file transfer application on the receiving end sends a second notification message to the file transfer application on the sending end to notify the file transfer application on the sending end to send the private file content.

[0181] S10: The file transfer application at the sending end reads the private file content of the third-party application according to the file descriptor.

[0182] Since the SDK integrated by the third-party application on the sending side returns the file descriptor of the private file to the file transfer application in step S4, after the file transfer application on the sending side obtains the file descriptor, it can directly use this file descriptor to access the content of the private file of the third-party application on the sending side without re-calling the open function to open the file, thereby bypassing the permission check.

[0183] It is understandable that step S10 can be executed before step S5, or step S10 can be executed simultaneously with step S5. In these possible implementations, the file transfer application on the sending side can send the private file content and the file path together to the file transfer application on the receiving side, and directly execute step S12 after executing steps S6 to S8.

[0184] S11: The file transfer application on the sending end sends the read private file content to the file transfer application on the receiving end.

[0185] S12: The file transfer application at the receiving end writes the private file content into the empty file according to the file descriptor corresponding to the opened empty file.

[0186] The file sharing method shown in the above embodiment has at least the following beneficial effects:

[0187] (1) Breaking through the limitations of traditional Linux file permissions

[0188] Android is a system based on the Linux kernel. Due to the limitation of Linux file permissions, one application cannot access the private files of another application. The file sharing method disclosed in this embodiment can break this limitation and allow one application to share its own files with another application.

[0189] (2) Security

[0190] Although the private files of one application can be accessed by another application, you can precisely control which application the file is shared with, and only authorized applications can access the shared files. Therefore, security can be guaranteed and the private files of the application will not be leaked.

[0191] Figure 6 600 is a block diagram of a file sharing device 600 shown in an embodiment of the present disclosure. The device is applied to a first electronic device, in which a first application and a second application are installed. Figure 6 The device 600 includes: a receiving module 610, a first transmission module 620 and a sending module 630, wherein:

[0192] The receiving module 610, a software development kit SDK for second application integration receives a call request of the first application; wherein the call request includes: a file path;

[0193] A first transfer module 620, used for the SDK to transfer the file path to the opening function of the second application, wherein the file path is used for the opening function to open the private file in the memory space of the first electronic device;

[0194] The sending module 630 is used for the SDK to return the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file.

[0195] In some embodiments, the sending module 630 includes:

[0196] The acquisition submodule is used by the SDK to obtain the file descriptor generated after the private file is opened in the memory space;

[0197] The sending submodule is used to send the file descriptor to the first application.

[0198] In some embodiments, the apparatus further comprises a determining module;

[0199] A determination module, used to determine the operation type of the first application operating the private file according to the call request;

[0200] The first transmission module 620 is specifically used for:

[0201] When the operation type is a read operation, the file path is passed to the open function of the second application.

[0202] In some embodiments, the apparatus further comprises a second delivery module;

[0203] A second transfer module, used for, when the operation type is a write operation, the SDK to transfer the file path to the creation function of the second application, wherein the creation function is used to create the first file in the file directory of the second application according to the file path;

[0204] The first transmission module 620 is specifically used for:

[0205] After the creation function completes the creation of the first file, the SDK passes the file path of the first file to the opening function of the second application.

[0206] In some embodiments, the apparatus further comprises a third transfer module and a fourth transfer module;

[0207] A third transfer module, configured to enable the SDK to transfer the file path to a delete function of the second application when the operation type is an update operation, wherein the delete function is configured to delete the second file of the second application according to the file path;

[0208] A fourth transfer module, used for the SDK to transfer the file path to the creation function of the second application, wherein the creation function is used to create a third file with the same name as the second file in the file directory of the second application according to the file path after the second file is deleted;

[0209] The first transmission module 620 is specifically used for:

[0210] After the creation function completes the creation of the third file, the SDK passes the file path of the third file to the opening function of the second application.

[0211] In some embodiments, the sending submodule is specifically used for:

[0212] The SDK sends the file information to the first application through a preset inter-process communication mechanism.

[0213] In some embodiments, the apparatus further comprises a verification module;

[0214] A verification module, used to perform identity verification on the first application according to the call request;

[0215] The first transmission module 620 is specifically used for:

[0216] After the identity verification of the first application is passed, the file path is passed to the open function of the second application.

[0217] In some embodiments, the verification module is specifically used to:

[0218] The SDK obtains the package name and signature information of the first application according to the application identifier;

[0219] The identity of the first application is verified according to the obtained package name and signature information.

[0220] Regarding the file sharing device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the file sharing method, and will not be elaborated here.

[0221] In an exemplary embodiment, the receiving module 610, the first transmission module 620 and the sending module 630, etc. can be implemented by one or more central processing units (CPU), graphics processing units (GPU), baseband processors (BP), application specific integrated circuits (ASIC), DSPs, programmable logic devices (PLD), complex programmable logic devices (CPLD), field programmable gate arrays (FPGA), general-purpose processors, controllers, microcontrollers (MCU), microprocessors, or other electronic components to execute the aforementioned method.

[0222] Figure 7 700 is a block diagram of another file sharing device 700 shown in an embodiment of the present disclosure. The device is applied to a first electronic device, in which a first application and a second application are installed. Figure 7 The device 700 includes: a first sending module 710, a first receiving module 720 and a processing module 730, wherein:

[0223] The first sending module 710 is used for the first application to send a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application;

[0224] The first receiving module 720 is used for the first application to receive the file information returned by the SDK; the file information is generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device;

[0225] The processing module 730 is used for the first application to process the private file in the memory space according to the file information.

[0226] In some embodiments, the processing module 730 is specifically configured to perform at least one of the following:

[0227] When the operation type associated with the call request is a read operation, the private file is read from the memory space according to the file information;

[0228] When the operation type associated with the call request is a write operation, write content to the first file opened in the memory space according to the file information; the first file is: a private file created by the SDK calling the creation function of the second application;

[0229] When the operation type associated with the call request is an update operation, the content is written to the third file opened in the memory space according to the file information; the third file is: the SDK calls the delete function of the second application to delete the second file with the same name as the third file and calls the create function to create a private file.

[0230] In some embodiments, the apparatus further comprises a second receiving module;

[0231] A second receiving module is used for the first application to receive the file content and file path sent by the second electronic device; wherein the file content is used for the first application to write the private file of the second application according to the file path;

[0232] In some embodiments, the apparatus further comprises a determining module;

[0233] The determination module is used to determine the file path according to the input operation of the user interface UI.

[0234] In some embodiments, the apparatus further comprises a second sending module;

[0235] The second sending module is used for the first application to send the file content of the private file of the second application and the file path of the private file in the file directory of the second application to the third electronic device.

[0236] Regarding the file sharing device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the file sharing method, and will not be elaborated here.

[0237] In an exemplary embodiment, the first sending module 710, the first receiving module 720 and the processing module 730, etc. can be implemented by one or more central processing units (CPU, Central Processing Unit), graphics processing units (GPU, Graphics Processing Unit), baseband processors (BP, baseband processor), application-specific integrated circuits (ASIC, Application Specific Integrated Circuit), DSP, programmable logic devices (PLD, Programmable Logic Device), complex programmable logic devices (CPLD, Complex Programmable Logic Device), field programmable gate arrays (FPGA, Field-Programmable Gate Array), general-purpose processors, controllers, microcontrollers (MCU, Micro Controller Unit), microprocessors (Microprocessors), or other electronic components to execute the aforementioned method.

[0238] Figure 8 800 is a block diagram of a computer device 800 shown in an embodiment of the present disclosure. For example, the computer device 800 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0239] Reference Figure 8 , the computer device 800 may include one or more of the following components: a processing component 802 , a memory 804 , a power component 806 , a multimedia component 808 , an audio component 810 , an input / output (I / O) interface 812 , a sensor component 814 , and a communication component 816 .

[0240] The processing component 802 generally controls the overall operation of the computer device 800, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 802 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0241] The memory 804 is configured to store various types of data to support operations on the device 800. Examples of such data include instructions for any application or method operating on the computer device 800, contact data, phone book data, messages, pictures, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0242] The power component 806 provides power to the various components of the computer device 800. The power component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the computer device 800.

[0243] The multimedia component 808 includes a screen that provides an output interface between the computer device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0244] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC), and when the computer device 800 is in an operating mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 804 or sent via the communication component 816. In some embodiments, the audio component 810 also includes a speaker for outputting audio signals.

[0245] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.

[0246] The sensor assembly 814 includes one or more sensors for providing various aspects of status assessment for the computer device 800. For example, the sensor assembly 814 can detect the open / closed state of the device 800, the relative positioning of components, such as the display and keypad of the computer device 800, and the sensor assembly 814 can also detect the position change of the computer device 800 or a component of the computer device 800, the presence or absence of user contact with the computer device 800, the orientation or acceleration / deceleration of the computer device 800, and the temperature change of the computer device 800. The sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0247] The communication component 816 is configured to facilitate wired or wireless communication between the computer device 800 and other devices. The computer device 800 can access a wireless network based on a communication standard, such as Wi-Fi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0248] In an exemplary embodiment, the computer device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the steps of the file sharing method in the above-described embodiments.

[0249] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, and the instructions can be executed by a processor 820 of a computer device 800 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0250] A computer readable storage medium, when the computer program is executed by a processor, implements the following steps:

[0251] The software development kit SDK integrated by the second application receives a call request of the first application; wherein the call request includes: a file path;

[0252] The SDK passes the file path to the open function of the second application, wherein the file path is used for the open function to open the private file in the memory space of the first electronic device;

[0253] The SDK returns the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file.

[0254] A computer readable storage medium, when the computer program is executed by a processor, implements the following steps:

[0255] The first application sends a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application;

[0256] The first application receives the file information returned by the SDK; the file information is generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device;

[0257] The first application processes the private file in the memory space according to the file information.

[0258] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. The present disclosure is intended to cover any variations, uses or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The description and examples are to be considered exemplary only, and the true scope and spirit of the present disclosure are indicated by the claims.

[0259] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A file sharing method, characterized in that: Applied to a first electronic device, in which a first application and a second application are installed, the method includes: The software development kit SDK integrated with the second application receives a call request of the first application; wherein the call request includes: a file path; The SDK passes the file path to the open function of the second application, wherein the file path is used for the open function to open the private file in the memory space of the first electronic device; The SDK returns the file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file; Determining, according to the calling request, an operation type of the first application operating the private file; When the operation type is an update operation, the SDK passes the file path to a delete function of the second application, wherein the delete function is used to delete the second file of the second application according to the file path; The SDK passes the file path to the creation function of the second application, wherein the creation function is used to create a third file with the same name as the second file in the file directory of the second application according to the file path after the second file is deleted; The SDK passes the file path to the opening function of the second application, including: After the creation function completes the creation of the third file, the SDK passes the file path of the third file to the opening function of the second application.

2. The method according to claim 1, characterized in that: The SDK returns the file information of the private file opened in the memory space to the first application, including: The SDK obtains a file descriptor generated after the private file is opened in the memory space; The file descriptor is sent to the first application.

3. The method according to claim 1, characterized in that The SDK passes the file path to the opening function of the second application, including: When the operation type is a read operation, the file path is passed to an open function of the second application.

4. The method according to claim 3, characterized in that: The method further comprises: When the operation type is a write operation, the SDK passes the file path to a creation function of the second application, wherein the creation function is used to create a first file in a file directory of the second application according to the file path; The SDK passes the file path to the opening function of the second application, including: After the creation function completes the creation of the first file, the SDK passes the file path of the first file to the opening function of the second application.

5. The method according to claim 2, characterized in that: The sending the file descriptor to the first application includes: The SDK sends the file information to the first application through a preset inter-process communication mechanism.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Performing identity verification on the first application according to the calling request; The SDK passes the file path to the opening function of the second application, including: After the identity verification of the first application is passed, the file path is passed to the open function of the second application.

7. The method according to claim 6, characterized in that The calling request carries an application identifier of the first application, and the identity verification of the first application according to the calling request includes: The SDK obtains the package name and signature information of the first application according to the application identifier; The identity of the first application is verified according to the obtained package name and signature information.

8. A file sharing method, characterized in that: Applied to a first electronic device, in which a first application and a second application are installed, the method includes: The first application sends a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application; The first application receives the file information returned by the SDK; the file information is generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device; The first application processes the private file in the memory space according to the file information, including: When the operation type associated with the calling request is an update operation, content is written to the third file opened in the memory space according to the file information; the third file is: a private file created by the SDK after calling the delete function of the second application to delete the second file with the same name as the third file and calling the create function.

9. The method according to claim 8, characterized in that The first application processes the private file in the memory space according to the file information, including at least one of the following: When the operation type associated with the call request is a read operation, reading the private file from the memory space according to the file information; When the operation type associated with the call request is a write operation, writing content to the first file opened in the memory space according to the file information; The first file is: a private file created by the SDK calling the creation function of the second application.

10. The method according to claim 8, characterized in that The method further comprises: The first application receives the file content and the file path sent by the second electronic device; wherein the file content is used for the first application to write the private file of the second application according to the file path; or, The file path is determined according to an input operation of the user interface UI.

11. The method according to claim 8, characterized in that The method further comprises: The first application sends the read file content of the private file of the second application and the file path of the private file in the file directory of the second application to the third electronic device.

12. A file sharing device, characterized in that: Applied to a first electronic device, in which a first application and a second application are installed, the device includes: A receiving module, a software development kit SDK for integrating the second application, receives a call request of the first application; wherein the call request includes: a file path; A first transfer module, configured for the SDK to transfer the file path to an open function of the second application, wherein the file path is used by the open function to open a private file in a memory space of the first electronic device; A sending module, configured for the SDK to return file information of the private file opened in the memory space to the first application, wherein the file information is used for the first application to operate the file content of the opened private file; a determination module, configured to determine, according to the call request, an operation type of the first application operating the private file; A third transmission module, configured to, when the operation type is an update operation, enable the SDK to transmit the file path to a deletion function of the second application, wherein the deletion function is configured to delete the second file of the second application according to the file path; A fourth transfer module, used for the SDK to transfer the file path to the creation function of the second application, wherein the creation function is used to create a third file with the same name as the second file in the file directory of the second application according to the file path after the second file is deleted; The first transfer module is further used for: after the creation function completes the creation of the third file, the SDK transfers the file path of the third file to the opening function of the second application.

13. A file sharing device, characterized in that: Applied to a first electronic device, in which a first application and a second application are installed, the device includes: A first sending module, configured for the first application to send a call request to the SDK integrated with the second application, wherein the call request includes: a file path of a private file of the second application; A first receiving module, configured for the first application to receive file information returned by the SDK; the file information is generated after the SDK calls the opening function of the second application to open the private file corresponding to the file path in the memory space of the first electronic device; A processing module is used for the first application to process the private file in the memory space according to the file information; including: when the operation type associated with the call request is an update operation, writing content to a third file opened in the memory space according to the file information; the third file is: a private file created after the SDK calls the delete function of the second application to delete the second file with the same name as the third file and calls the create function.

14. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the file sharing method described in any one of claims 1 to 7 are implemented; or, when the processor executes the program, the steps of the file sharing method described in any one of claims 8 to 11 are implemented.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the file sharing method described in any one of claims 1 to 7 are implemented; or, when the computer program is executed by a processor, the steps of the file sharing method described in any one of claims 8 to 11 are implemented.

Images