Mounting method and electronic device

Abstract

The present application relates to the technical field of terminals. Provided are a mounting method and an electronic device. In the present application, a public file of an application can be mounted in a device power-on process, such that only a private file of the application needs to be mounted in the subsequent process of application process incubation, thereby improving application process incubation efficiency and reducing user waiting time. The method comprises: in response to a power-on operation by a user, an electronic device configures a public mounting point, the public mounting point being used for mounting a public file, the public file being a resource accessible to both first and second applications in the electronic device, and the first application and the second application being different; and in response to a startup event of the first application, the electronic device configures a first mounting point for the first application, the first mounting point being used for mounting a private file of the first application, the private file of the first application being a resource accessible to the first application alone, and the first mounting point being a sub-mounting point of the public mounting point.

Description

Mounting method and electronic device

[0001] The present application claims priority to the Chinese patent application No. 202411334070.0, filed on September 23, 2024, and entitled "Mounting method and electronic device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the technical field of terminal, and in particular, to a mounting method and an electronic device. BACKGROUND

[0003] Generally, a sandbox isolation technology is used to create an isolated environment to run a code or an application program, so as to ensure that the running will not cause potential security risks to the system or other programs. Optionally, the sandbox types of an operating system generally include three types, such as an application process sandbox, a system process sandbox, and a chipset component process sandbox. Among them, each process can only access the files within the sandbox design range when running, and cannot access the global file system, so as to enhance the security.

[0004] In some examples, each application process is configured with an independent sandbox to isolate the running of each application process and ensure the security of the application running. Then, during the hatching process of the application process, the mounting points required by the application process sandbox need to be mounted in full. However, the number of mounting points is large, which leads to a slow application process hatching process, a long user waiting time, and an impact on the user experience. SUMMARY

[0005] In order to solve the above technical problems, the present application provides a mounting method and an electronic device. The technical scheme provided by the present application can complete the mounting of application public files during the booting process of the device, so that only application private files need to be mounted during the subsequent application process hatching process, thereby improving the application process hatching efficiency and reducing the user waiting time.

[0006] In order to achieve the above technical purposes, the present application provides the following technical scheme:

[0007] In a first aspect, a mounting method is provided, applied to an electronic device, and the method comprises: in response to a user's booting operation, configuring a public mounting point, the public mounting point being used to mount a public file, the public file being a resource accessed by both a first application and a second application in the electronic device, the first application and the second application being different; in response to a starting event of the first application, configuring a first mounting point of the first application, the first mounting point being used to mount a private file of the first application, the private file of the first application being a resource accessed by the first application alone, and the first mounting point being a sub-mounting point of the public mounting point.

[0008] Therefore, by the staged mounting, only the private mounting point (e.g., the first mounting point) of the application needs to be mounted in the application starting process, so that the application starting time is effectively reduced, and the user waiting time is reduced.

[0009] In addition, by the staged mounting, the mounting of the public files of all the applications is completed in the booting process of the electronic device, and repeated mounting of the same mounting point in the starting processes of different applications is avoided.

[0010] In some examples, during the running of the first application, the resources that need to be accessed by the first application include public resources (e.g., resources in the public files) and private resources (e.g., resources in the private files). The public files are mounted at the public mounting point, and the resources in the public files can be accessed through the public mounting point. The private files are mounted at the private mounting point, and the resources in the private files can be accessed through the private mounting point.

[0011] According to the first aspect, the method further includes: in response to a starting event of a second application, configuring a second mounting point of the second application, the second mounting point being used to mount private files of the second application, wherein the private files of the second application are resources that are individually accessed by the second application, and the second mounting point is a sub-mounting point of the public mounting point.

[0012] In response to the application starting event, the application enters the hatching process, and the application process is created.

[0013] Therefore, in the starting processes of different applications, the configuration of the private mounting point of each application can be completed based on the same public mounting point, and the hatching efficiency of the application is effectively improved.

[0014] According to the first aspect, or any one of the implementations of the first aspect, in response to the starting event of the first application, the first mounting point of the first application is configured, including: in response to the starting event of the first application, creating a first application process corresponding to the first application, and configuring the first mounting point to which the file content to be added is based on the public mounting point. A first namespace is created. In the first namespace, the first application process mounts the private files of the first application at the first mounting point to which the file content to be added is.

[0015] Therefore, before the namespace unique to the application is created, the first application process can reuse the public files and configure the first mounting point to which the file content to be added is. In this way, after the namespace is created, the private files can be added in the first mounting point, the private file isolation based on the namespace is implemented, and the directory structure of each application process in the sandbox is the same, but the actual file content of each application is different.

[0016] According to a first aspect, or any of the implementations of the first aspect, the mounting phase of the first application comprises a first mounting phase, a second mounting phase and a third mounting phase, the first mounting phase is a phase of configuring the common mounting point before starting the first application, the second mounting phase is a phase of configuring the first mounting point of the to-be-added file content during starting the first application, and the third mounting phase is a phase of mounting the private file of the first application under the first mounting point of the to-be-added file content during starting the first application.

[0017] Exemplarily, the first mounting phase is a common mounting phase, the second mounting phase is a mounting phase before creating the namespace, and the third mounting phase is a mounting phase after creating the namespace.

[0018] In this way, by mounting in stages, the mounting of the common file of the entire application is completed in the common mounting phase before starting the application, and only the private mounting point of the application needs to be mounted during starting the application, thereby effectively reducing the application starting time and reducing the user waiting time.

[0019] According to the first aspect, or any of the implementations of the first aspect, in response to the boot operation of the user, the common mounting point is configured, comprising: in response to the boot operation of the user, configuring the first common mounting point in the common mounting point by a share manner. The method further comprises: in the running process of the first application, in response to a first mounting point update event, updating the first common mounting point and the first sub-mounting point of the first common mounting point, and the first application obtaining an update result of the first common mounting point and the first sub-mounting point.

[0020] In some examples, the mounting point is configured by the share manner, so that the mounting point and the sub-mounting point of the mounting point have the ability of update transmission. For example, after the mounting point is updated by the share manner, the update of the mounting point is also transmitted to the sub-mounting point of the mounting point, thereby ensuring the consistency of the state between the parent mounting point and the sub-mounting point.

[0021] In this way, by defining the updateable mounting point, the problem that the mounting point cannot be updated after the mounting is completed is solved.

[0022] According to the first aspect, or any of the implementations of the first aspect, the first mounting point update event comprises invalidation of the first common file under the first common mounting point or system file update.

[0023] According to the first aspect, or any one of the implementations of the first aspect, the configuring the first mount point of the first application in response to the start event of the first application comprises: configuring, in response to the start event of the first application, a third mount point of the to-be-added file content by the share mode, the first mount point comprising the third mount point. The method further comprises: in the running process of the first application, in response to a second mount point update event, updating, by the first application process, the third mount point of the to-be-added file content, the third mount point of the to-be-added file content being unmounted with the first private file or having mounted the first private file.

[0024] In this way, by defining an updatable mount point, the problem that a mount point cannot be updated after the mount is completed is solved.

[0025] According to the first aspect, or any one of the implementations of the first aspect, the second mount point update event comprises any one of the following situations: the third mount point of the to-be-added file content fails to mount, the unlocking event and the first application being an application running before unlocking, the first private file being invalid, and the first private file being updated.

[0026] For example, the first application is running, and the electronic device is locked. Subsequently, in the first unlocking process of the electronic device, the third mount point of the first application can fail to mount. Then, based on the third mount point configured by the share mode, a second update can be automatically triggered. Then, the third mount point and the sub-mount points of the third mount point are remounted, so that the first application can be normally run subsequently.

[0027] According to the first aspect, or any one of the implementations of the first aspect, the electronic device is configured with a mount point combination, and the mount point combination comprises a plurality of sub-mount points. The method further comprises: in a case where a fourth mount point meets a preset condition, mounting the plurality of sub-mount points, the fourth mount point being the common mount point or the first mount point, and the preset condition comprising the first permission or the first working mode.

[0028] For example, the same mount point needs to be mounted under multiple permissions. Then, the mount points can be combined to obtain a mount point combination. Subsequently, the mount point combination is added to the corresponding permission. Alternatively, the permission can be defined by the preset condition.

[0029] For example, whether the common mount point or the private mount point meets the preset condition, the corresponding mount point combination can be mounted.

[0030] In this way, by using the mount point combination configuration scheme, the mounting process of the regular mount point is realized.

[0031] According to a first aspect, or any of the implementations of the first aspect, the electronic device comprises a configuration file, the configuration file being configured to indicate a dependency relationship of the mounting paths of the plurality of sub-mounting points.

[0032] In this way, during the application development, the developer can directly download the configuration file, and add the corresponding mounting points in the application as the mounting dependency paths and the mounting paths in the configuration file. It is not necessary to establish the dependency relationship between different mounting points one by one, thereby reducing the difficulty of application development.

[0033] According to the first aspect, or any of the implementations of the first aspect, the configuration file is further configured to modify the dependency relationship.

[0034] In this way, the difficulty of application upgrade development is reduced.

[0035] According to the first aspect, or any of the implementations of the first aspect, the mounting of the plurality of sub-mounting points comprises: mounting a second sub-mounting point in the plurality of sub-mounting points first, and mounting a third sub-mounting point in the plurality of sub-mounting points, the mounting path of the third sub-mounting point depending on the mounting path of the second sub-mounting point.

[0036] In this way, the ordered mounting of the plurality of sub-mounting points in the mounting point combination is realized through the predefined dependency relationship.

[0037] According to the first aspect, or any of the implementations of the first aspect, before the mounting of the plurality of sub-mounting points, the method further comprises: configuring the second sub-mounting point through a share manner.

[0038] In this way, through the mounting point combination mechanism, the repeated mounting points are classified, thereby standardizing the mounting process. In combination with the above-mentioned share manner, through the mounting point combination mechanism, the mounting points with the dependency relationship are processed, thereby improving the mounting efficiency.

[0039] According to the first aspect, or any of the implementations of the first aspect, the method further comprises: in response to an exit event of the first application, unmounting the first mounting point.

[0040] In some examples, the exit event of the first application comprises, for example, an event of exiting the first application in response to a user operation, an abnormal exit of the first application, etc. Optionally, the exit event of the first application comprises, for example, an end of an application process of the first application. It should be understood that when the first application is running in the background, the process of the first application is not ended, and then the first mounting point is not unmounted.

[0041] In some examples, in response to the exit event of the first application, only the private mount point of the first application, such as the first mount point, is unmounted, and the public mount point is not unmounted. Thus, in subsequent application startup processes, the private mount point of other applications can be mounted based on the public mount point that is not unmounted.

[0042] In this way, in response to the exit of the first application, the electronic device can automatically unmount the private mount point of the first application, end the running of the first application, and achieve flexible loading and unloading of the private mount point of the application.

[0043] In a second aspect, an electronic device is provided. The electronic device includes a processor and a memory. The memory is coupled to the processor, and the memory is configured to store computer program codes including computer instructions. When the processor reads the computer instructions from the memory, the electronic device is caused to perform the following: in response to a startup operation of a user, configuring a public mount point, the public mount point being used to mount a public file, the public file being a resource accessed by a first application and a second application in the electronic device, the first application and the second application being different; and in response to a startup event of the first application, configuring a first mount point of the first application, the first mount point being used to mount a private file of the first application, the private file of the first application being a resource accessed by the first application alone, the first mount point being a sub-mount point of the public mount point.

[0044] According to the second aspect, when the processor reads the computer instructions from the memory, the electronic device is further caused to perform the following: in response to a startup event of the second application, configuring a second mount point of the second application, the second mount point being used to mount a private file of the second application, the private file of the second application being a resource accessed by the second application alone, the second mount point being a sub-mount point of the public mount point.

[0045] According to the second aspect, or any one of the implementations of the second aspect, in response to the startup event of the first application, configuring the first mount point of the first application includes: in response to the startup event of the first application, creating a first application process corresponding to the first application, and configuring the first mount point of the to-be-added file content according to the public mount point. A first namespace is created. In the first namespace, the first application process mounts the private file of the first application under the first mount point of the to-be-added file content.

[0046] According to the second aspect, or any one of the implementations of the second aspect, the mounting stage of the first application includes a first mounting stage, a second mounting stage, and a third mounting stage. The first mounting stage is a stage of configuring the public mount point before the first application is started. The second mounting stage is a stage of configuring the first mount point of the to-be-added file content during the startup process of the first application. The third mounting stage is a stage of mounting the private file of the first application under the first mount point of the to-be-added file content during the startup process of the first application.

[0047] According to a second aspect, or any possible implementation mode of the second aspect, in response to the boot operation of the user, the common mount point is configured, including: in response to the boot operation of the user, a first common mount point in the common mount point is configured by a share mode. When the processor reads the computer instruction from the memory, the electronic device further performs: in the running process of the first application, in response to a first mount point update event, the first common mount point and a first sub-mount point of the first common mount point are updated, and the first application obtains an update result of the first common mount point and the first sub-mount point.

[0048] According to the second aspect, or any possible implementation mode of the second aspect, the first mount point update event includes invalidation of a first common file under the first common mount point or system file update.

[0049] According to the second aspect, or any possible implementation mode of the second aspect, in response to the start event of the first application, the first mount point of the first application is configured, including: in response to the start event of the first application, a third mount point of to-be-added file content is configured by a share mode, and the first mount point includes the third mount point. When the processor reads the computer instruction from the memory, the electronic device further performs: in the running process of the first application, in response to a second mount point update event, a first application process updates the third mount point of the to-be-added file content, and the third mount point of the to-be-added file content is not mounted with the first private file or has been mounted with the first private file.

[0050] According to the second aspect, or any possible implementation mode of the second aspect, the second mount point update event includes any one of the following situations: the third mount point of the to-be-added file content fails to be mounted, the unlocking event and the first application is an application running before unlocking, the first private file is invalid, and the first private file is updated.

[0051] According to the second aspect, or any possible implementation mode of the second aspect, the electronic device is configured with a mount point combination, and the mount point combination includes a plurality of sub-mount points. When the processor reads the computer instruction from the memory, the electronic device further performs: in the case that a fourth mount point meets a preset condition, the plurality of sub-mount points are mounted, the fourth mount point is a common mount point or a first mount point, and the preset condition includes a first permission or a first working mode.

[0052] According to the second aspect, or any possible implementation mode of the second aspect, the electronic device includes a configuration file, and the configuration file is used to indicate a dependency relationship of mounting paths of the plurality of sub-mount points.

[0053] According to the second aspect, or any possible implementation mode of the second aspect, the configuration file is further used to modify the dependency relationship.

[0054] According to a second aspect, or any possible implementation mode of the second aspect, mounting the plurality of sub-mounting points comprises: mounting a second sub-mounting point in the plurality of sub-mounting points first, and mounting a third sub-mounting point in the plurality of sub-mounting points, wherein the mounting path of the third sub-mounting point depends on the mounting path of the second sub-mounting point.

[0055] According to the second aspect, or any possible implementation mode of the second aspect, before mounting the plurality of sub-mounting points, the method further comprises: configuring the second sub-mounting point in a share mode.

[0056] According to the second aspect, or any possible implementation mode of the second aspect, when the processor reads the computer instructions from the memory, the electronic device is further caused to perform: in response to an exit event of the first application, unmounting the first mounting point.

[0057] A third aspect provides an electronic device having a function of implementing the method in the first aspect and any possible implementation mode of the first aspect. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0058] A fourth aspect provides a computer-readable storage medium. The computer-readable storage medium stores a computer program (also referred to as instructions or code), which, when executed by an electronic device, causes the electronic device to perform the method in the first aspect or any implementation mode of the first aspect.

[0059] A fifth aspect provides a computer program product, which, when executed on an electronic device, causes the electronic device to perform the method in the first aspect or any implementation mode of the first aspect.

[0060] A sixth aspect provides circuitry, which includes processing circuitry configured to perform the method in the first aspect or any implementation mode of the first aspect.

[0061] A seventh aspect provides a chip system, which includes at least one processor and at least one interface circuit. The at least one interface circuit is configured to perform a transceiving function and send instructions to the at least one processor. When the at least one processor executes the instructions, the at least one processor performs the method in the first aspect or any implementation mode of the first aspect.

[0062] The technical effects of the foregoing aspects can be referred to each other, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0063] FIG. 1 is a schematic diagram of a global file system mounting structure provided by an embodiment of the present application;

[0064] FIG. 2 is a schematic diagram of a mounting process according to an embodiment of the present application;

[0065] FIG. 3 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present application;

[0066] FIG. 4 is a schematic diagram of a mounting method according to an embodiment of the present application;

[0067] FIG. 5 is a schematic diagram of an initial mounting relationship according to an embodiment of the present application;

[0068] FIG. 6 is a schematic diagram of a scenario of updating mounting points for all applications during device operation according to an embodiment of the present application;

[0069] FIG. 7 is a schematic diagram of a scenario of updating mounting points for part of applications during device operation according to an embodiment of the present application;

[0070] FIG. 8 is a schematic diagram of a mounting method according to an embodiment of the present application;

[0071] FIG. 9 is a schematic diagram of a structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0072] The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing the specific embodiments and are not intended to be limiting on the present application. As used in the specification and the appended claims of the present application, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that “at least one” and “one or more” refer to one or two or more (including two).

[0073] In the present specification, the phrase “one embodiment” or “some embodiments” etc. means that a particular feature, structure or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, the phrases “in one embodiment”, “in some embodiments”, “in other some embodiments”, “in yet some embodiments” etc. appearing in different places in the present specification are not necessarily all referring to the same embodiment, but mean “one or more but not all embodiments”, unless otherwise specifically noted. The terms “comprising”, “including”, “having” and their conjugates mean “including but not limited to”, unless otherwise specifically noted. The term “connected” includes both direct and indirect connections, unless otherwise specifically noted. “First”, “second”, etc. are used only for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features.

[0074] In the embodiments of the present application, the word "exemplarily" or "for example" is used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. In fact, the word "exemplarily" or "for example" is intended to present the relevant concept in a specific manner.

[0075] In some embodiments, a global file system (GFS) is configured in the electronic device, and the storage resources are managed through the GFS. The GFS is part of the file system architecture of the operating system, and the storage resources in the GFS can be accessed through a mount point. Optionally, the mount point is a directory in the file system, which allows other file systems or devices to be mounted under the directory, so that these resources can be accessed under the mount point.

[0076] Exemplarily, as shown in FIG. 1, the mount points commonly used in the GFS include, for example, a data mount point (data), a sandbox environment mount point (sandbox), a virtual file system mount point (proc), a system mount point (system), a temporary mount point (mnt), a device file mount point (dev), a vendor file mount point (vendor), another virtual file system mount point (sys), and the like. Among them, the data is usually used to store application data or user data, and can be shared and accessed by multiple system nodes. The sandbox can be used for a secure sandbox environment, limiting programs to run in an isolated environment to prevent affecting other parts of the system. The proc provides information of the kernel and processes. The system can be used to store system-level files and resources. The mnt is used to temporarily mount external storage devices or file systems. The dev represents various hardware devices in the system, providing an access interface to the hardware. The vendor is usually used to store system files or drivers specific to the vendor, and is used to distinguish components provided by third-party vendors in some systems. The sys provides information interaction with the kernel and system devices, similar to the proc, and is used for device management and system state query. These mount points help to organize and manage system resources and files, and ensure the normal operation of the system and the consistency of data.

[0077] Each mount point can further mount other sub-mount points. For example, the sub-mount points under system include a mount point lib for storing system shared library files, a mount point bin for storing basic commands and executable files of the system, a mount point etc containing system configuration files, and the like. For another example, as shown in FIG. 1, the sandbox includes three types of sandboxes, i.e., an application process sandbox, a system component process sandbox, and a chip component process sandbox. The three types of sandboxes can further mount various types of mount points, which include a sandbox root directory, and read-only directories and writable directories mounted under the sandbox root directory. The read-only files under the read-only directories are only allowed to be read by processes, and are not allowed to be written. The writable files under the writable directories are allowed to be read and written by processes.

[0078] Optionally, the application process sandbox is a technology for running an application program in an isolated environment to prevent it from causing damage to the system or other application programs. The sandbox restricts the access of the application program to system resources such as the file system, network, and process, ensuring that even if the application program contains malicious code or has vulnerabilities, it will not affect the main system. The system component process sandbox is used to isolate the core components and services of the operating system to improve the security and stability of the system. It ensures that even if the system components are attacked or have vulnerabilities, they will not have a widespread impact on the main system. The chip component process sandbox (also known as hardware sandbox or hardware isolation) is a security technology designed to isolate and protect critical functions and data within the chip to prevent malicious attacks or data breaches.

[0079] Optionally, the system component process sandbox and the chip component process sandbox can share a sandbox for multiple processes, while the application process sandbox is configured with an independent sandbox for each application for isolation.

[0080] Illustratively, the file system visible to each application process runtime is actually constructed by multiple mount points. For example, as shown in FIG. 1, the application process sandbox includes at least one read-only mount point and at least one writable mount point. As shown in FIG. 2, the application process sandbox adopts a configurable design, and the mounting process and the mount point are separated, thereby facilitating the extension of the mount point, such as adding a new mount point. During the application process incubation process, the sandbox environment of the application can be obtained according to the application incubation context and the sandbox configuration file. The application incubation context includes a package name and permissions. The package name indicates the mounting path of the mount point, and the permissions indicate the number of mount points. Optionally, the application process incubation process includes, for example, a startup process of the application, in which a corresponding application process is created, thereby realizing the incubation of the application process.

[0081] Generally, during the application process incubation process, the application needs to mount all the required mount points. In the case of a large number of mount points, the application process incubation process can be slow, and the user waiting time can be long.

[0082] In the mounting based on the package name, a security risk of counterfeit package name obtaining system data can occur. In addition, if the package name or the mounting point with the same permission can be repeatedly mounted, the mounting point can be covered, and data loss or permission change can occur.

[0083] In addition, after the application process is hatched, all mounting points of the application process are mounted. During the application running process, the application process has no permission to modify the mounting points of the application process. That is, the application process does not support the ability of updating the mounting points after mounting. However, in some scenarios, the mounting points can need to be updated during the application running process. For example, in some mounting decryption mounting point scenarios, the first mounting can fail, and the support of the secondary mounting update can cause the application process to be unable to obtain the files under the mounting point.

[0084] To this end, the application provides a mounting method, which can complete the mounting of application public files during the device startup process, so that only the application private files need to be mounted during the subsequent application process hatching process, the application process hatching efficiency is improved, and the user waiting time is reduced.

[0085] Optionally, the mounting method provided by the application embodiment can be applied to an electronic device 100. Optionally, the electronic device 100 can be, for example, a terminal device such as a mobile phone, a tablet computer, a personal computer (PC), an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), a wearable device, a vehicle terminal, an artificial intelligence (AI) device, and the like. The operating system installed on the electronic device 100 includes, but is not limited to Android, iOS, Windows, or other operating systems. The application does not limit the specific type of the electronic device 100 or the operating system installed thereon.

[0086] For example, FIG. 3 shows a structural schematic diagram of the electronic device 100.

[0087] The electronic device 100 can include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a key 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, and the like.

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

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

[0090] The internal memory 121 can be used to store computer executable program codes including instructions. The internal memory 121 can include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required by a function (such as a sound playing function, an image playing function, etc.), and the like. The data storage area can store data (such as audio data, a phone book, etc.) created during use of the electronic device 100, and the like. In addition, the internal memory 121 can include a high-speed random access memory, and can further include a non-volatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash storage (UFS), and the like. The processor 110 performs various function applications and data processing of the electronic device 100 by executing instructions stored in the internal memory 121 and / or instructions stored in a memory disposed in the processor.

[0091] Hereinafter, the mounting method provided by the embodiments of the present application will be described in detail with the electronic device 100 as an example.

[0092] In some embodiments, a plurality of applications are installed in the electronic device, and different applications can configure independent sandbox environments during running to ensure the security of application running. Optionally, the application process completes mounting of required mounting points during the application process hatching. Optionally, different applications can have some same mounting points. In some examples, if the same mounting points are mounted first after the electronic device is started, the same mounting points do not need to be mounted again during the subsequent application process hatching, thereby effectively improving the application process hatching efficiency.

[0093] In some examples, the electronic device can divide the mounting points corresponding to each application into required mounting points and conditional mounting points according to the necessity of the mounting points. The required mounting points are mounting points that need to be mounted during the hatching process of each application process. The conditional mounting points are mounting points that need to be mounted during the hatching process of an application process with specific permissions or in a specific working mode. For example, only applications with specific permissions are allowed to mount the conditional mounting points. For example, only applications with some system features (such as backup and recovery) need to mount the conditional mounting points. The hatching capability bit information of the application can be obtained to determine whether the application has the corresponding system features. For example, only in the case of extended data (such as a harmony shared package (HSP)) during the hatching process, the conditional mounting points need to be mounted.

[0094] In some examples, the electronic device can divide the mounting points corresponding to each application into system-constant mounting points and application-variable mounting points according to variability of the mounting points. The system-constant mounting points are mounting points with the same source mounting path in the process of hatching of different application processes of the same user. The application-variable mounting points are mounting points with different source mounting directories in the process of hatching of different application processes of the same user.

[0095] In some embodiments, the mandatory mounting points or the system-constant mounting points are mounting points that all applications in the electronic device need to mount, and correspond to public files of the applications. The conditional mounting points or the application-variable mounting points are mounting points that different applications in the electronic device need to mount individually, and correspond to private files of the applications.

[0096] Optionally, the mounting points include public mounting points and private mounting points. The public mounting points are mounting points that all applications need to mount, and include the mandatory mounting points or the system-constant mounting points. The private mounting points are mounting points that different applications need to mount individually, and include the conditional mounting points or the application-variable mounting points.

[0097] In some examples, the electronic device is configured with a global file system (GFS) for managing storage resources. Optionally, the storage resources in the electronic device include resources that all applications need to access in the process of running (such as public files), and resources that different applications need to access individually in the process of running (such as private files). Optionally, the mounting points are directories in the GFS, and a directory allowing mounting of public files is, for example, a public mounting point, and a directory allowing mounting of private files is, for example, a private mounting point.

[0098] For example, as shown in FIG. 1, the mounting points in the application process sandbox include read-only mounting points and writable mounting points. Optionally, the public mounting points that all applications need to mount are, for example, read-only mounting points, which are used to mount public files of all applications. The private mounting points that different applications need to mount individually are, for example, writable mounting points, which are used to mount private files corresponding to the applications.

[0099] For example, the read-only mounting points include, for example, a mounting point config used to store configuration files and setting files of applications or systems, a mounting point dev representing various hardware devices in the system and providing an access interface to the hardware, a mounting point proc providing information of the kernel and the process, a system mounting point system used to store system-level files and resources, a mounting point vendor used to store vendor-specific files and libraries, and part of the public mounting points in a mounting point data used to store data, such as a mounting point lib used to store system shared library files.

[0100] For example, the writable mount points include private mount points in the mount point data, such as the mount point storage for storing user data and application data.

[0101] In some embodiments, the mount stages of the mount points involved in the application process hatching process can be divided into a global mount stage (STAGE_GLOBAL) and an application local mount stage (STAGE_APP_LOCAL), for example. The global mount stage is used to mount common mount points that all applications in the electronic device need to mount, such as mandatory mount points and system-level constant mount points. The application local mount stage is used to mount private mount points that different applications need to mount individually, such as conditional mount points or application-level variable mount points.

[0102] For example, in response to the start of the electronic device, the global mount stage is entered. In the global mount stage, the electronic device mounts mount points that all applications in the electronic device need to mount. After that, in the application process hatching process, the corresponding application process only needs to mount the mount points required by the application process, and the common mount points that all applications need to mount do not need to be mounted repeatedly, thereby effectively improving the application process hatching efficiency.

[0103] Optionally, the common mount points mounted in the global mount stage point to common files of all applications in the electronic device, and the private mount points mounted in the application local mount stage point to private files of the respective applications.

[0104] In some embodiments, as shown in Table 1 below, in response to the start of the electronic device, the global mount stage is entered, and a corresponding mount namespace (mount namespace) is created, such as a root namespace, to mount the common files of the applications in the root namespace. The mount namespace is a type of Linux namespace that is used to isolate the mount points of the file system, and it allows a process to see different file system views in different mount namespaces. For example, a process in a sandbox can have its own independent file system view, which does not affect the file system view of the host system or other sandboxes. In the global mount stage, the root namespace is created to isolate the common mount points.

[0105] Optionally, as shown in Table 1 below, the root namespace is used to mount the common mount points that each application needs to mount once at the start of the electronic device. Moreover, these common mount points do not need to be unmounted during the running process of the electronic device after the start, so as to facilitate the reuse of the common mount points by subsequent application processes.

[0106] Table 1

[0107] The following describes each mounting stage of the mounting point in detail.

[0108] FIG. 4 is a flowchart illustrating a mounting method according to an embodiment of the present application. It should be noted that the method is not limited to the specific order described in FIG. 4 and the following description, and it should be understood that in other embodiments, the order of some steps in the method can be exchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0109] S401, in response to a boot-up, entering a common mounting stage, and mounting common files of applications by an application hatcher component (appspawn).

[0110] In some embodiments, the electronic device is configured with an application hatcher component (appspawn), which is an open source tool for dynamically creating and managing instances (such as application processes) of application programs on the electronic device. For example, the appspawn provides an automated function to manage application processes, such as starting, stopping, restarting, etc. For another example, the appspawn runs application processes in a controlled environment (such as a sandbox environment) to minimize the mutual influence between application processes.

[0111] In some examples, in response to a boot-up of the electronic device, the appspawn is triggered to initialize. During the initialization of the appspawn, the appspawn mounts common mounting points (such as mandatory mounting points and system-level constant mounting points). Optionally, the common mounting points correspond to common files of all applications in the electronic device.

[0112] For example, as shown in Table 1 above, in response to a boot-up of the electronic device, the appspawn creates a root namespace to mount common files of applications in the root namespace during the common mounting stage. In this example, the appspawn creates the root namespace to isolate the common mounting points.

[0113] It should be understood that step S401 is an optional step, which is performed during the boot-up of the electronic device, and in the subsequent running stage after the boot-up of the electronic device, step S401 is not performed, and the mounting of private files in the application process hatching process is completed by steps S402-S407.

[0114] S402, an ability manager service (AMS) sends an application process hatching request to the appspawn.

[0115] The AMS is used to manage the life cycle and capabilities (such as services, components) of an application, for example, in an operating system or application framework. For example, the AMS can be used to manage the start, stop, restart, and the like of an application, to ensure that the application runs as expected. For another example, the AMS can also be used to register and manage various capabilities or components of an application, to ensure that they can interact normally. For another example, the AMS can also be used to allocate necessary resources and permissions when an application is started, to optimize the performance and stability of the application. For another example, the AMS can also be used to obtain the status of an application and its components in real time, to handle abnormal situations, and to maintain the health status of the system.

[0116] In some embodiments, in response to an operation of indicating to start an application by a user, the electronic device triggers the AMS to send an application process hatching request to the appspawn, to indicate that the application currently needs to enter the hatching stage of the application indicated to start by the user. Correspondingly, the appspawn receives the application process hatching request sent by the AMS, and obtains the application currently needing to enter the hatching stage.

[0117] Optionally, the operation of indicating to start an application includes, for example, an operation of a user on an application icon displayed by the electronic device, an operation of indicating to start an application by voice, an operation of triggering to start another application program in a certain application program by a user, and the like.

[0118] S403, creating an application process.

[0119] S404, entering a mounting stage before namespace creation, and mounting a file directory.

[0120] In some embodiments, in response to the application process hatching request, the appspawn creates a new application process, which is a process corresponding to the application currently entering the hatching stage.

[0121] In some examples, the appspawn derives a child process (such as an application process) from an existing process by using a fork function. The fork function can be used to generate a new process (such as a child process) that is almost identical to the existing process, and the child process starts execution from the current position of the parent process but has an independent address space. Optionally, the existing process is, for example, the process (such as the appspawn process) that has mounted the common files of the application. In this way, after the application process is created, the common files that have been mounted can be directly reused, and the subsequent private file mounting process can be continued after the common files.

[0122] In some embodiments, after the application process is forked, the appspawn can also mount the file directory corresponding to the application process to reuse the common files that have been mounted. Optionally, the file directory mounted by the appspawn points to the common files that have been mounted, for example. Optionally, the file directory mounted by the appspawn also includes the file directories corresponding to the private files, but no files are currently mounted under these file directories, and the mounting of the private files needs to be completed through the following step S405. For example, after the application process is created, the appspawn can obtain the file directories corresponding to all the files needed in the current application running process, including the file directories corresponding to the common files and the file directories corresponding to the private files, and among them, the common files have been mounted through the above step S401.

[0123] In this way, by creating a forked child process, the common mount point is reused, and the problem of multiple mountings of the same mount point in different applications is avoided.

[0124] In some embodiments, as described above, the sandbox environment isolation of different application processes is achieved by mounting the namespace, and then the appspawn can create a new mount namespace for mounting the private mount point of the application.

[0125] In some examples, before creating the new mount namespace, the appspawn can obtain the file directories, mounting capabilities, and the like of the application according to the configuration file of the application. Optionally, the mounting capabilities include mount point passing capabilities, mount point secondary update capabilities, and the like. Among them, the mount point passing capability indicates whether the application process has the capability to copy the common mount point and to perform subsequent private mount point mounting based on the common mount point. The mount point secondary update capability indicates whether the mount point has the capability to update the mount point, and the mount point secondary update capability will be described in detail in the related embodiments below, and will not be described here.

[0126] In some examples, as shown in Table 1 above, the mounting stage before creating the new namespace is, for example, the mounting stage before creating the namespace (STAGE_PRE_UNSHARE). Among them, in the STAGE_PRE_UNSHARE, the appspawn mounts the application-differentiated mount points in the root namespace, and these mount points are mount points that are operated together with the root namespace process.

[0127] Exemplarily, as mentioned above, the data mount point includes part of the common mount point (e.g., the mount point lib) and part of the private mount point (e.g., the mount point storage). Then, at the STAGE_PRE_UNSHARE, the appspawn can mount the file directory corresponding to the part of the private mount point in the root namespace. Subsequently, after the application process completes the creation of the new namespace, the application process can mount the private files required in the file directory corresponding to the part of the private mount point, so that the directory structure of each application process in the sandbox is the same, but the actual file content of each application is different. For example, the appspawn mounts an empty storage. Alternatively, the appspawn can mount multiple sub-mount points under the storage. Subsequently, the application process can mount the private files under the empty mount point (see the following step S405 for details).

[0128] In some examples, as shown in Table 1 above, during the exit of the application, the appspawn can unload the content mounted at the STAGE_PRE_UNSHARE, so as to realize the management of the application process by the appspawn.

[0129] Alternatively, the application process can also realize the mounting of the file directory after the creation is completed. That is, the process of mounting the file directory by the appspawn in each of the above embodiments can also be realized by the application process.

[0130] S405, create a namespace, and enter a post-namespace-creation mounting stage to mount the application private files in the file directory.

[0131] In some embodiments, the appspawn creates a new namespace (e.g., an application namespace (app namespace)) by using an unshare command. The unshare command is a command for Linux systems, which allows to isolate some resources of a running program, such as the file system, process ID, or network resource, and create a new namespace.

[0132] Alternatively, at the STAGE_PRE_UNSHARE, the appspawn obtains the application with the mount point passing capability, and triggers the creation of a new namespace to mount the private files in the new namespace.

[0133] In some embodiments, as shown in Table 1 above, after the creation of the namespace, the post-namespace-creation mounting stage (STAGE_POST_UNSHARE) can be entered. Alternatively, at the STAGE_POST_UNSHARE, the application process can mount the application differentiated mount point (e.g., the private mount point of the application process) in the app namespace.

[0134] In some embodiments, at STAGE_POST_UNSHARE, the application process can change the root file system of the current process to another file system through a Pivot root function to implement different root file system mounting.

[0135] Exemplarily, the application process creates a new namespace through the unshare command, and the new namespace copies the public mount point which has completed mounting. Then, the application process can perform mounting of the private mount point based on the public mount point through the Pivot root function. For example, the public mount point includes a data mount point, and the mount point data mounts a public mount point lib and a private mount point storage. Wherein, the application process can obtain the file directory mounted at STAGE_PRE_UNSHARE, and the file directory includes the mounting structure relationship of each mount point. Then, the application process can change the private mount point storage in the file directory through the Pivot root function to mount the private mount point of the application under the private mount point storage, and the private mount point can point to the private file of the application.

[0136] Wherein, STAGE_POST_UNSHARE can also be described as an application local mounting stage (STAGE_APP_LOCAL) for mounting the private file of the application in the app namespace unique to the application.

[0137] In some embodiments, as shown in Table 1 above, during the application exit process, the kernel can automatically unload the private mount point mounted by the application process at STAGE_POST_UNSHARE.

[0138] S406, the application process sends a mounting completion indication to the appspawn.

[0139] S407, the appspawn sends an application process hatching completion response to the AMS.

[0140] In some embodiments, after completing the mounting of the private mount point, the application process can send a mounting completion indication to the appspawn to indicate that the appspawn has completed all the mounting of the mount point at present. Correspondingly, the appspawn determines that all the mounting of the mount point has been completed according to the mounting completion indication sent by the application process. Then, the appspawn can send an application process hatching completion response to the AMS. Correspondingly, the AMS can determine that the application process has completed hatching according to the application process hatching completion response received. Then, the electronic device can normally start the application and display the corresponding application interface.

[0141] Thus, by the staged mounting, only the private mounting points of the application need to be mounted in the application process hatching process, effectively reducing the application process hatching time and reducing user waiting time.

[0142] In addition, by the staged mounting, the same mounting point is avoided from being mounted repeatedly by different applications.

[0143] In addition, by the staged mounting, conditional private mounting point mounting according to permissions, hatching capability bits, or extension data is implemented, and the scalability of the application process mounting is enhanced.

[0144] In some embodiments, the application can also complete the mounting of the private mounting points before creating the namespace by the unshare method in the first hatching process. Then, in the process of hatching the application again, all the mounted mounting points that have been hatched can be directly reused, and there is no mounting time consumption, further improving the application hatching efficiency.

[0145] In some scenarios, after the application process is hatched, all the mounting points of the application process have completed the mounting. In addition, the application process does not have the permission to modify its own mounting points during the running of the application process. Therefore, in some cases, due to the inability to update the mounting points, the application process may run abnormally.

[0146] Optionally, in a preset scenario, the electronic device may need to update the mounting points. Optionally, the preset scenario includes, for example, a scenario in which the mounting of a file under a mounting point fails in a previous mounting process, or a scenario in which a mounted file under a mounting point is invalid. The invalidity of the file includes, for example, the existence of an updated version of the file corresponding to the file.

[0147] For example, the application has run before the screen is locked, that is, the mounting of all the mounting points has been completed. Subsequently, the electronic device is locked, and the application belongs to the application running before the screen is locked, and the data under part of the private mounting points may also be locked. After the electronic device is unlocked, the part of the private mounting points is mounted for the first time, which may cause the mounting of the files under the private mounting points to fail, and then the part of the private mounting points may need to be mounted again. However, due to the limitation that the application process does not have the permission to modify its own mounting points, the application process cannot directly mount the part of the private mounting points again. For example, the mounting point data mounts the private mounting point storage, and the private mounting point mounts the mounting point el2, which can be used to store group information related to user authentication and authorization and the like. Then, after the electronic device is unlocked, the mounting point el2 needs to be mounted again.

[0148] For example, after the nweb framework is upgraded, each application process needs to update the resource directory mounting point of the nweb, and obviously the application processes include the application processes that have been hatched. The nweb framework is a lightweight web framework, which is usually used in embedded systems or resource isolated environments to provide basic web server functions, static file services, and the like.

[0149] Therefore, the embodiment of the present application provides a mounting method, which can realize the secondary update capability of the mounting point. The secondary update process of the mounting point is described in detail below.

[0150] In some embodiments, the mounting point that can be updated during the running of the application process is referred to as updatable.

[0151] In some embodiments, a root mounting point of MS_SHARED is built for the updatable mounting point, so that the corresponding updatable can be updated during the running of the application process.

[0152] Optionally, the shared mounting option is used to set the sharing attribute of the mounting point. For example, the shared mounting option can control the visibility and transitivity of the mounting point in the sub-mounting point. If new mounting points are created under a shared mounting point, the changes of the new mounting points will also be transmitted to the shared mounting point, so as to ensure the consistency of the states between the parent mounting point and the sub-mounting point.

[0153] For example, the system service process updates the updatable mounting point under the MS_SHARED mounting point in the root namespace, so as to realize the update of the mounting point during the running of the application process. Optionally, the MS_SHARED mounting point is referred to as updatable-root.

[0154] Optionally, each updatable mounting point needs to belong to an updatable-root mounting point.

[0155] In some embodiments, in the process of mounting the file directory by the appspawn in the STAGE_PRE_UNSHARE, whether the mounting point in the file directory has the secondary update capability of the mounting point can be obtained. Optionally, the mounting point with the secondary update capability of the mounting point can be set as the updatable-root mounting point. In this way, subsequently, the updatable mounting point mounted under the updatable-root mounting point can be updated when the secondary update is needed.

[0156] In some embodiments, the update scenarios of the updatable mount points include a common mount point secondary update scenario and a partially applied mount point secondary update scenario. The common mount point secondary update scenario includes, for example, a secondary update of a required mount point (required) and a secondary update of a system-const mount point. The partially applied mount point secondary update scenario includes, for example, a secondary update of a conditional mount point (conditional) or a secondary update of an app-variable mount point.

[0157] Optionally, for the partially applied mount point secondary update scenario, the mount points of the partial application can be unmounted during the exit process of the partial application, including the updatable-root mount point and the updatable mount point.

[0158] For example, as shown in FIG. 5, at STAGE_GLOBAL, the application common files mounted by the appspawn include application common file A and application common file B. At STAGE_PRE_UNSHARE, the file directories mounted by the appspawn include the private file directory of application 1 and the private file directory of application 2. Subsequently, after the appspawn creates the application processes and the namespaces, the application process corresponding to application 1 can mount private files in the private file directory of application 1, such as private file 1 of application 1 and private file 2 of application 1. In this way, the application process corresponding to application 1 can obtain all the completed mount points of application 1. In addition, the application process corresponding to application 2 can mount private files in the private file directory of application 2, such as private file 1 of application 2 and private file 2 of application 2. In this way, the application process corresponding to application 2 can obtain all the completed mount points of application 2. The foregoing process is the initial mount relationship establishment process.

[0159] Based on the initial mounting relationship of the example of FIG. 5, for the scenario of secondary update of the common mounting point, the required common mounting point can be configured in the process of establishing the initial mounting relationship in the MS_SHARED mode. In this way, in the secondary update process, the system process (such as the appspawn process) can update the sub-mounting point (such as the updatable mounting point) mounted under the MS_SHARED in the root namespace. For example, as shown in FIG. 6, in the process of establishing the initial mounting relationship, the appspawn configures the mounting point corresponding to the application common file B in the MS_SHARED mode. Then, in the running process of the electronic device, the system process can update the mounting point corresponding to the application common file B in the root namespace, and the sub-mounting point mounted under the mounting point corresponding to the application common file B is also updated accordingly, such as the mounting point corresponding to the common file C is also updated. Then, based on the initial mounting relationship that has been created, the application process corresponding to the application 1 that has been hatched and the application process corresponding to the application 2, the mounting point corresponding to the application common file B and the mounting point corresponding to the common file C in the two application processes are also updated.

[0160] Based on the initial mounting relationship of the example of FIG. 5, for the scenario of secondary update of the mounting point of part of the application, the required private mounting point can be configured in the process of establishing the initial mounting relationship in the MS_SHARED mode. In this way, in the secondary update process, the application process can update the sub-mounting point (such as the updatable mounting point) mounted under the MS_SHARED in the corresponding app namespace. For example, as shown in FIG. 7, in the process of establishing the initial mounting relationship, the appspawn configures the file directory of the application 2 to include the MS_SHARED, such as configuring the mounting point corresponding to the private file 2 of the application 2 in the MS_SHARED mode. Then, in the running process of the electronic device, the application process corresponding to the application 2 can update the mounting point corresponding to the private file 2 of the application 2 in the app namespace of the application 2 according to the file directory, and the sub-mounting point mounted under the mounting point corresponding to the private file 2 is also updated accordingly, such as the mounting point corresponding to the private file D is also updated. Moreover, the secondary update of the mounting point corresponding to the private file of the application 2 does not affect the mounting point in the currently running application 1.

[0161] In this way, by defining the updatable mounting point, the problem that the mounting point cannot be updated after the mounting is completed is solved. Moreover, the mounting process is managed in stages, and better management effect is achieved.

[0162] The secondary update process of the mounting point will be described in detail below by taking the secondary update process of the el2 mounting point as an example.

[0163] Exemplarily, in the step S404, in response to the application hatching request, the appspawn creates the application process A in the STAGE_PRE_UNSHARE, and mounts the el2 mounting point in the MS_SHARED mode, such as mounting an empty el2 source directory for the el2 directory of the application. After the application process A is hatched, the electronic device detects the unlocking operation after the screen is locked, and the AMS can obtain the unlocking operation and send the unlocking notification to the appspawn. In response to the unlocking notification, the appspawn obtains the application process A running before the screen is locked, and obtains the el2 source directory mounted in the MS_SHARED mode in the file directory mounted by the application process A. Then, the appspawn can mount the corresponding private file under the el2 source directory, so as to realize the capability of updating the mounting point during the running of the application process. Subsequently, during the exit of the application corresponding to the application process A, the appspawn can unload the mounting point corresponding to the application process A, such as the el2 mounting point and the sub-mounting point mounted under the el2 mounting point.

[0164] The above describes the mounting stages in the application hatching process and the updateable mounting point, and the following describes the combined mounting scenario of the mounting points with the same permission.

[0165] In some embodiments, the same mounting point needs to be mounted under multiple permissions. Then, the mounting points can be combined to obtain a MountPointGroup. Then, the MountPointGroup is added to the corresponding permission. For example, multiple mounting points need to mount the el2 mounting point. Then, the el2 mounting point can be added to the MountPointGroup, and the MountPointGroup is added to the multiple mounting points which need to mount the el2 mounting point. In this way, the mounting process of the regular mounting point is realized through the MountPointGroup configuration scheme.

[0166] Optionally, the MountPointGroup can be defined under the named-groups field, which is used to combine multiple mounting points of the same type.

[0167] In some embodiments, there is a time sequence dependency relationship between different mounting points, such as the time sequence dependency relationship of the mounting point data, the mounting point storage, and the mounting point el2: the mounting point data is the parent mounting point of the mounting point storage, and the mounting point storage depends on the mounting point data in time sequence; the mounting point storage is the parent mounting point of the mounting point el2, and the mounting point el2 depends on the mounting point storage in time sequence.

[0168] Optionally, based on the time sequence dependency between different mount points, a named-group can be defined. The named-group includes mount-paths-deps and mount-paths. The mount points that are depended on are defined by mount-paths-deps, and the mount points under mount-paths are mounted after the mount points in mount-paths-deps are mounted.

[0169] For example, mount point 1 and mount point 2 in an application both need to mount mount point A and mount point B under the same permission. Then, mount point A and mount point B can be configured as a named-group, and the named-group is configured as mount-paths. Mount point 1 is configured as the corresponding mount-paths-deps, and mount point 2 is configured as the corresponding mount-paths-deps. In this way, it is not necessary to separately configure that the sub-mount points of mount point 1 include mount point A and mount point B, and the sub-mount points of mount point 2 include mount point A and mount point B, thereby reducing the repeated configuration process. Instead, the same named-group can be reused through the time sequence relationship between mount-paths-deps and mount-paths, so that mount point 1 and mount point 2 can both mount mount point A and mount point B in the named-group, thereby improving the configuration efficiency.

[0170] For another example, a certain mount point in application 1 and a certain mount point in application 2 both need to mount mount point A and mount point B under the same permission. Then, mount point A and mount point B can be configured as a named-group, and the named-group is configured as mount-paths. The corresponding mount points in application 1 and application 2 are respectively configured as mount-paths-deps. In this way, the named-group can be reused to improve the configuration efficiency under the condition of meeting the configuration requirements.

[0171] In some embodiments, during the application development process, the developer can create the named-group relationship between different mount points, so as to realize the sequential mounting of multiple mount points in the named-group in the application hatching process after the electronic device installs the application.

[0172] In some embodiments, the template file is preconfigured, for example, as a configuration file, to define the named-group, and to define the mount-paths-deps and the mount-paths in the named-group. In this way, during the application development process, the developer can directly download the configuration file, and add the corresponding mount point in the application as the mount-paths-deps or the mount-paths in the configuration file. In this way, it is not necessary to establish the named-group relationship between different mount points one by one, thereby reducing the difficulty of application development.

[0173] In some examples, in the case that the application needs to add some functions (or described as capabilities), it is not necessary to modify the source code of the application, but can directly modify the dependency relationship indicated in the named-group in the configuration file to achieve the addition of the functions. In this way, the difficulty of application upgrade development is reduced.

[0174] In some embodiments, based on the above introduction of the mount point secondary update scenario, the mount-paths-deps can be configured in the MS_SHARED mode. In this way, after the application process is hatched, the named-group can also be updated by specifying the name.

[0175] Exemplarily, taking the configuration of the mount point el2 as the mount-paths-deps in the MS_SHARED mode as an example, the configuration process of the named-group is introduced. As shown in Table 2, the meanings of the fields of the following code for configuring the named-group are introduced. Among them, R / O indicates that the current field is a required field or an optionally field. The field type is string, indicating that the field is used to store text data. The field type is MountPath, indicating that the field is used to indicate the mount path. As can be seen, by defining the mount point el2 as the mount-paths-deps, and configuring the mount point el2 in the MS_SHARED mode, the mount of the mount point el2 and its child mount points in order is achieved. And the secondary update of the mount point el2 and its child mount points is achieved.

[0176] Table 2

[0177] In this way, through the named-group mechanism, the repeated mount points are classified, thereby standardizing the mount process. And in combination with the above example MS_SHARED mode, through the named-group mechanism, the mount points with dependency relationship are processed, thereby improving the mount efficiency.

[0178] In addition, by means of the staged mounting and the named-group mechanism, in the application hatching process, the mounting point can no longer be configured simply by means of the package name, the security risk of obtaining system data by means of a fake package name can be avoided, and the mounting point covering, data loss or permission change caused by the repeated mounting of the mounting points with the same package name or permission can be avoided.

[0179] FIG. 8 is a flowchart of a mounting method provided by an embodiment of the present application. It should be noted that the method is not limited to the specific order described in FIG. 8 and the following description, and it should be understood that in other embodiments, the order of some steps of the method can be exchanged according to actual needs, or some steps of the method can be omitted or deleted. The method includes the following steps:

[0180] S801, in response to a user's boot operation, the electronic device configures a common mounting point.

[0181] The common mounting point is used to mount a common file of an application in the electronic device, and the common file is a resource that needs to be accessed by all applications in the electronic device. For example, the electronic device is installed with a first application and a second application. Then, the first application and the second application need to access the resource in the common file during running.

[0182] In some embodiments, the mounting points include common mounting points and private mounting points. The common mounting points are mounting points that need to be mounted by all applications, for example, including mandatory mounting points or system-level constant mounting points. The private mounting points are mounting points that need to be mounted individually by different applications, for example, including conditional mounting points or application-level variable mounting points. Alternatively, the common mounting points point to the common files of all applications in the electronic device; and the private mounting points point to the private files of the respective applications.

[0183] In some embodiments, in response to the booting of the electronic device, the electronic device enters a common mounting stage triggered by mounting, creates a root namespace, and configures the common mounting point in the root namespace to mount the common files of all applications included in the current electronic device.

[0184] In this way, by means of the staged mounting, the mounting of the common files is completed in the device booting stage, and in the subsequent application hatching process, the common files do not need to be mounted repeatedly, thereby effectively reducing the mounting pressure of the application hatching process.

[0185] In some embodiments, in a preset scenario, it can be necessary to update the mounting points, that is, the secondary update capability of the mounting points needs to be configured. Alternatively, the mounting points that can be updated during the running of the application process are referred to as updateable mounting points.

[0186] Optionally, the preset scenario includes a scenario that a file under a mount point fails to be mounted in a previous mounting process, or a scenario that a mounted file under a mount point is invalid. The invalid file includes an updated version of the file, for example.

[0187] In some examples, the mount point is configured in a share mode, so that the mount point and a sub-mount point of the mount point have the capability of update transmission. For example, after the mount point is mounted in the share mode, the update of the mount point is transmitted to the sub-mount point of the mount point, so as to ensure the consistency of the states between the parent mount point and the sub-mount point.

[0188] In some examples, the mount point configured in the share mode can be a public mount point or a private mount point.

[0189] Optionally, in response to the boot operation of the user, the public mount point is configured, including: in response to the boot operation of the user, the first public mount point in the public mount point is configured in the share mode. Then, subsequently, in the running process of the first application, in response to a first mount point update event, the first public mount point and a first sub-mount point of the first public mount point are updated, and the first application obtains the update result of the first public mount point and the first sub-mount point.

[0190] The first mount point update event includes invalidation of a first public file under the first public mount point or update of a system file.

[0191] For example, in the boot phase of the electronic device, the electronic device configures a first public mount point in the share mode, and the first public mount point points to a first public file. Then, subsequently, in the running process of the electronic device, the first public file can be invalid. For example, after the nweb framework is upgraded, some system files are updated, and the original system files corresponding to the first public file are invalid. Therefore, the electronic device needs to update the first public mount point corresponding to the first public file, and after the first public mount point is updated in the share mode, a first sub-mount point of the first public mount point is also updated. The first application that is currently running has mounted the first public mount point. Therefore, in this case, the first application can directly synchronize to obtain the update result of the first public mount point and the first sub-mount point.

[0192] For example, as shown in FIG. 6, in the process of establishing the initial mounting relationship, the appspawn configures the mounting point corresponding to the application public file B in the MS_SHARED mode. Then, during the running of the electronic device, the system process can update the mounting point corresponding to the application public file B in the root namespace, and the sub-mounting points mounted under the mounting point corresponding to the application public file B are also updated accordingly, such as the mounting point corresponding to the public file C is also updated. Then, based on the initial mounting relationship that has been created, the mounting point corresponding to the application public file B and the mounting point corresponding to the public file C in the application process corresponding to the application 1 and the application process corresponding to the application 2, which have been hatched, are also updated.

[0193] In this way, by defining the updateable mounting point, the problem that the mounting point cannot be updated after the mounting is completed is solved.

[0194] S802, in response to the starting event of the first application, the electronic device configures a first mounting point of the first application.

[0195] The first mounting point is used to mount the private file of the first application, the private file of the first application is a resource that needs to be accessed by the first application alone, and the first mounting point is a sub-mounting point of the common mounting point. For example, during the running of the first application, the resources that need to be accessed include common resources (such as resources in the public file) and private resources (such as resources in the private file). Among them, the public file is mounted in the common mounting point, and the resources in the public file can be accessed through the common mounting point, and the private file is mounted in the private mounting point, and the resources in the private file can be accessed through the private mounting point.

[0196] In some embodiments, in response to the starting event of the first application, a first application process corresponding to the first application is created, and the first mounting point to which the file content is to be added is configured according to the common mounting point. Then, the electronic device creates a first namespace. In the first namespace, the first application process mounts the private file of the first application under the first mounting point to which the file content is to be added.

[0197] Optionally, the mounting stage of the first application includes a first mounting stage, a second mounting stage and a third mounting stage, the first mounting stage is a stage of configuring the common mounting point before the first application is started, the second mounting stage is a stage of configuring the first mounting point to which the file content is to be added during the starting process of the first application, and the third mounting stage is a stage of mounting the private file of the first application under the first mounting point to which the file content is to be added during the starting process of the first application.

[0198] Exemplarily, as shown in Table 1 above, the first mounting stage is a global mounting stage (STAGE_GLOBAL), the second mounting stage is a pre-namespace-creation mounting stage (STAGE_PRE_UNSHARE), and the third mounting stage is a post-namespace-creation mounting stage (STAGE_POST_UNSHARE).

[0199] Then, in step S801, the electronic device enters the first mounting stage in response to device startup and completes mounting of the global mount point. Subsequently, in step S802, in response to a startup event of the first application, the second mounting stage is entered, and the appspawn creates the first application process. After the first application process is created, the global file can be directly reused. Alternatively, in the second mounting stage, the appspawn mounts the file directories corresponding to the first application process, and based on reuse of the global file, these file directories include file directories pointing to the global file (i.e., the global mount point) and file directories that should point to the private file of the first application (i.e., the private mount point). It should be understood that, in the second mounting stage, because the private file of the first application has not been mounted, the file directories that should point to the private file of the first application are empty, i.e., the file directories exist but are blank. Then, the appspawn creates a namespace corresponding to the first application process, and enters the third mounting stage. In the third mounting stage, the first application process can mount the private file of the first application in the empty file directories, thereby completing mounting of all mount points of the first application.

[0200] In this way, by mounting in stages, only the private mount point of the application needs to be mounted in the application process hatching process, effectively reducing the application process hatching time and reducing the user waiting time.

[0201] Furthermore, by mounting in stages, mounting of the global file of all applications is completed in the global mounting stage, avoiding repeated mounting of the same mount point in the subsequent application hatching process.

[0202] In some embodiments, as described in step S801 above, the mount point configured by the share mode can be a global mount point or a private mount point. Then, in the first application process hatching process, the private mount point of the first application can also be configured by the share mode, to realize the secondary update capability of the mount point.

[0203] In some examples, in response to the start event of the first application, the first application process configures a third mount point of the to-be-added file content in the share manner, and the first mount point includes the third mount point. Then, subsequently, in response to a second mount point update event during running of the first application, the first application process updates the third mount point of the to-be-added file content, and the first private file is not mounted in the third mount point of the to-be-added file content or has been mounted in the third mount point of the to-be-added file content.

[0204] Optionally, the second mount point update event includes any one of the following: the third mount point of the to-be-added file content fails to be mounted, the unlocking event and the first application is an application running before unlocking, the first private file is invalid, and the first private file is updated.

[0205] For example, the electronic device is locked during running of the first application. Subsequently, during the first unlocking of the electronic device, the third mount point of the first application can fail to be mounted. Then, based on the third mount point configured in the share manner, a second update can be automatically triggered. Then, the third mount point and the sub-mount points of the third mount point are remounted, so that the first application can be normally run subsequently.

[0206] For another example, the third mount point in the running first application has been mounted, but the first private file pointed to by the third mount point is invalid or exists an update. Then, based on the third mount point configured in the share manner, a second update can be automatically triggered. Then, the third mount point and the sub-mount points of the third mount point are remounted, so that the first application can be normally run subsequently.

[0207] Exemplarily, as shown in FIG. 7, during establishment of the initial mount relationship, the appspawn configures the file directory of the application 2 to include the MS_SHARED, that is, the mount point corresponding to the private file 2 of the application 2 is configured in the MS_SHARED manner. Then, during running of the electronic device, the application process of the application 2 can update the mount point corresponding to the private file 2 of the application 2 in the app namespace of the application 2 according to the file directory, and the sub-mount points mounted under the mount point corresponding to the private file 2 are also updated, such as the mount point corresponding to the private file D. Moreover, the second update of the mount point corresponding to the private file of the application 2 does not affect the mount point in the currently running application 1.

[0208] In this way, by defining the updateable mount point, the problem that the mount point cannot be updated after being mounted is solved.

[0209] In some embodiments, in response to a start event of the second application, a second mount point of the second application is configured, the second mount point being used for mounting private files of the second application, wherein the first application and the second application are different applications, the private files of the second application are resources accessed by the second application alone, and the second mount point is a sub-mount point of the common mount point. It should be understood that the first application copies the common mount point by means of forking in the hatching process, and creates a sub-mount point (such as the first mount point) based on the copied common mount point in the namespace of the first application. The second application copies the common mount point by means of forking in the hatching process, and creates a sub-mount point (such as the second mount point) based on the copied common mount point in the namespace of the second application.

[0210] In this way, different applications can complete the configuration of their own private mount points based on the same common mount point in the hatching process, thereby effectively improving the hatching efficiency of the applications.

[0211] In some embodiments, the electronic device is configured with a mount point combination, the mount point combination including a plurality of sub-mount points. In a case where a fourth mount point meets a preset condition, the electronic device mounts the plurality of sub-mount points. The fourth mount point is the common mount point or the first mount point, and the preset condition includes the first permission or the first working mode.

[0212] For example, the same mount point needs to be mounted under multiple permissions. In this case, the mount points can be combined to obtain a mount point combination. Then, the mount point combination is added to the corresponding permission. Alternatively, the permission can be defined by the preset condition. That is, the fourth mount point meeting the first permission or the fourth mount point in the first working mode can mount the mount point combination.

[0213] For example, whether the common mount point or the private mount point meets the preset condition, the corresponding mount point combination can be mounted.

[0214] In this way, the repeated mount points are classified by means of the mount point combination mechanism, thereby standardizing the mounting process.

[0215] In some embodiments, the electronic device includes a configuration file, the configuration file being used to indicate a dependency relationship of mount paths of the plurality of sub-mount points.

[0216] In this way, in the application development process, the developer can directly download the configuration file, and add the corresponding mount points in the application as the mount-paths-deps and the mount-paths in the configuration file. It is not necessary to establish the dependency relationship between different mount points one by one, thereby reducing the difficulty of application development.

[0217] In some examples, the configuration file is also used to modify the dependency relationship.

[0218] For example, when the application needs to add some functions (or described as capabilities), the source code of the application does not need to be modified, but the dependency relationship indicated in the mount point combination in the configuration file can be directly modified to add the functions.

[0219] In this way, the difficulty of application upgrade development is reduced.

[0220] In some embodiments, the electronic device mounts a plurality of sub-mount points, including: mounting a second sub-mount point in the plurality of sub-mount points first, and mounting a third sub-mount point in the plurality of sub-mount points second. The mounting path of the third sub-mount point depends on the mounting path of the second sub-mount point.

[0221] In this way, the pre-defined dependency relationship is used to realize the ordered mounting of the plurality of sub-mount points in the mount point combination.

[0222] In some examples, the second sub-mount point is configured by the share mode.

[0223] In this way, the mechanism of the mount point combination is used to realize the classification of the repeated mount points, thereby standardizing the mounting process. In combination with the above example of the share mode, the mount point combination mechanism is used to realize the processing of the mount points with dependency relationship, thereby improving the mounting efficiency.

[0224] In some embodiments, in response to an exit event of the first application, the electronic device unmounts the first mount point.

[0225] In some examples, the exit event of the first application includes, for example, an event of exiting the first application in response to a user operation, an abnormal exit of the first application, etc. Alternatively, the exit event of the first application includes, for example, the end of the application process of the first application. It should be understood that when the first application runs in the background, the process of the first application is not ended, and the electronic device does not unmount the first mount point.

[0226] In some examples, in response to the exit event of the first application, the electronic device only unmounts the private mount point of the first application, such as the first mount point, but does not unmount the public mount point. In this way, in the subsequent starting process of other applications, the electronic device can also mount the private mount point of other applications based on the public mount point that has not been unmounted.

[0227] In this way, in response to the exit of the first application, the electronic device can automatically unmount the private mount point of the first application to end the running of the first application, thereby realizing the flexible loading and unloading of the private mount point of the application.

[0228] The mounting method provided by the embodiments of the present application is described in detail above in combination with FIG. 4-FIG. 8. The electronic device provided by the embodiments of the present application is described in detail below in combination with FIG. 9.

[0229] In a possible design, FIG. 9 is a structural schematic diagram of an electronic device provided by the embodiments of the present application. As shown in FIG. 9, the electronic device 900 can include a transceiver unit 901 and a processing unit 902. The electronic device 900 can be used to implement the functions of the electronic device 100 involved in the above method embodiments.

[0230] Optionally, the transceiver unit 901 is configured to receive a user operation, for example, to support the electronic device 900 to perform S401 in FIG. 4; and / or, to support the electronic device 900 to perform S801 in FIG. 8.

[0231] Optionally, the processing unit 902 is configured to support the electronic device 900 to perform S401-S407 in FIG. 4; and / or, to support the electronic device 900 to perform S801 and S802 in FIG. 8.

[0232] The transceiver unit can include a receiving unit and a sending unit, can be implemented by a transceiver or a transceiver related circuit component, and can be a transceiver or a transceiver module. The operations and / or functions of each unit in the electronic device 900 are respectively used to implement the corresponding procedures of the mounting method described in the above method embodiments. All related contents of each step involved in the above method embodiments can be referred to the function description of the corresponding functional unit, and will not be described here in detail for the sake of brevity.

[0233] Optionally, the electronic device 900 shown in FIG. 9 can further include a storage unit (not shown in FIG. 9), and the storage unit stores programs or instructions. When the transceiver unit 901 and the processing unit 902 execute the programs or instructions, the electronic device 900 shown in FIG. 9 can perform the mounting method described in the above method embodiments.

[0234] The technical effects of the electronic device 900 shown in FIG. 9 can refer to the technical effects of the mounting method described in the above method embodiments, which will not be described here in detail.

[0235] In addition to the form of the electronic device 900, the technical solutions provided by the embodiments of the present application can also be functional units or chips in the electronic device, or devices matched with the electronic device.

[0236] The embodiments of the present application also provide a chip system, including a processor, the processor is coupled with a memory, the memory is used for storing programs or instructions, when the programs or instructions are executed by the processor, the chip system implements the method in any of the above method embodiments.

[0237] Optionally, the processor in the chip system can be one or more. The processor can be implemented by hardware or software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented by software, the processor can be a general-purpose processor, which is implemented by reading software code stored in a memory.

[0238] Optionally, the memory in the chip system can also be one or more. The memory can be integrated with the processor or arranged separately from the processor, and the embodiments of the present application do not limit the arrangement. For example, the memory can be a non-transient processor, such as a read-only memory (ROM), which can be integrated on the same chip as the processor or arranged on different chips, and the embodiments of the present application do not limit the type of memory or the arrangement of the memory and the processor.

[0239] For example, the chip system can be an FPGA, an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a PLD, or other integrated chips.

[0240] It should be understood that each step in the above method embodiments can be completed by the integrated logic circuit of hardware in the processor or the instructions in the form of software. The method steps disclosed in the embodiments of the present application can be directly embodied as hardware processor execution or executed by a combination of hardware and software modules in the processor.

[0241] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program. When the computer program is run on a computer, the computer is caused to execute the above related steps to implement the mounting method in the above embodiments.

[0242] The embodiments of the present application also provide a computer program product, which, when run on a computer, causes the computer to execute the above related steps to implement the mounting method in the above embodiments.

[0243] In addition, an apparatus is also provided in the embodiments of the present application. The apparatus can be specifically a component or a module, and can include one or more processors and memories connected thereto. The memories are configured to store computer programs. When the computer programs are executed by the one or more processors, the apparatus performs the mounting method in the above-mentioned method embodiments.

[0244] The apparatus, the computer readable storage medium, the computer program product or the chip provided in the embodiments of the present application are all used to execute the corresponding method provided above. Therefore, the beneficial effects achieved thereby can refer to the beneficial effects in the corresponding method provided above, which will not be repeated here.

[0245] The steps of the methods or algorithms described in connection with the embodiments disclosed in the present application can be implemented in hardware, or be implemented by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in a random access memory (RAM), a flash memory, a read only memory (ROM), an erasable programmable ROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a compact disk (CD-ROM) or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC.

[0246] From the above description of the embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration. In actual applications, the above functions can be completed by different functional modules according to needs; that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the functions described above. The specific working process of the above-mentioned system, apparatus and unit can refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

[0247] In several embodiments provided in the present application, it should be understood that the disclosed method can be implemented in other ways. The above-described device embodiments are only illustrative. For example, the division of the modules or units is only a logical function division, and actual implementation can have another division manner; for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed units can be indirect coupling or communication connection through some interfaces, modules or units, which can be electrical, mechanical or other forms.

[0248] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0249] The computer readable storage medium includes, but is not limited to, any one of the following: a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, and various media capable of storing program codes.

[0250] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited to this. Any change or replacement within the technical scope disclosed in the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A mounting method characterized by comprising: The method is applied to an electronic device, and comprises: In response to a user's boot operation, a common mount point is configured, the common mount point being used for mounting a common file, the common file being a resource accessed by both a first application and a second application in the electronic device, the first application and the second application being different; In response to a start event of the first application, a first mount point of the first application is configured, the first mount point being used for mounting a private file of the first application, the private file of the first application being a resource accessed by the first application alone, the first mount point being a sub-mount point of the common mount point.

2. The method of claim 1, wherein, The method further comprises: In response to a start event of the second application, a second mount point of the second application is configured, the second mount point being used for mounting a private file of the second application, wherein the private file of the second application is a resource accessed by the second application alone, and the second mount point is a sub-mount point of the common mount point.

3. The method according to claim 1 or 2, characterized in that, The response to the start event of the first application to configure the first mount point of the first application comprises: In response to the start event of the first application, a first application process corresponding to the first application is created, and the first mount point to which file content is to be added is configured according to the common mount point; A first namespace is created; In the first namespace, the first application process mounts the private file of the first application under the first mount point to which the file content is to be added.

4. The method of claim 3, wherein, The mounting stage of the first application comprises a first mounting stage, a second mounting stage, and a third mounting stage, the first mounting stage being a stage of configuring the common mount point before the first application is started, the second mounting stage being a stage of configuring the first mount point to which the file content is to be added during the start of the first application, and the third mounting stage being a stage of mounting the private file of the first application under the first mount point to which the file content is to be added during the start of the first application.

5. The method according to any one of claims 1 to 4, characterized in that, The response to the user's boot operation to configure the common mount point comprises: In response to the user's boot operation, a first common mount point in the common mount point is configured by a share mode. The method further comprises: During the running of the first application, in response to a first mount point update event, the first common mount point and a first sub-mount point of the first common mount point are updated, and the first application obtains an update result of the first common mount point and the first sub-mount point.

6. The method of claim 5, wherein, The first mount point update event comprises invalidation of a first common file under the first common mount point or system file update.

7. The method according to any one of claims 1 to 6, characterized in that, The response to the start event of the first application to configure the first mount point of the first application comprises: In response to the start event of the first application, a third mount point to which file content is to be added is configured by a share mode, and the first mount point comprises the third mount point. The method further comprises: In the running of the first application, in response to a second mount point update event, the first application process updates a third mount point of the to-be-added file content, and the third mount point of the to-be-added file content is not mounted with the first private file or has mounted the first private file.

8. The method of claim 7, wherein, The second mount point update event includes any one of the following cases: the third mount point of the to-be-added file content fails to mount, an unlocking event and the first application is an application running before unlocking, the first private file is invalid, and the first private file is updated.

9. The method according to any one of claims 1 to 8, characterized in that, The electronic device is configured with a mount point combination, and the mount point combination includes a plurality of sub-mount points; the method further includes: In the case that the fourth mount point meets a preset condition, the plurality of sub-mount points are mounted, the fourth mount point is a public mount point or the first mount point, and the preset condition includes a first permission or a first working mode.

10. The method of claim 9, wherein, The electronic device includes a configuration file, and the configuration file is used to indicate a dependency relationship of a mounting path of the plurality of sub-mount points.

11. The method of claim 10, wherein, The configuration file is also used to modify the dependency relationship.

12. The method according to any one of claims 9-11, characterized in that, The mounting of the plurality of sub-mount points includes: The second sub-mount point in the plurality of sub-mount points is mounted first, and then the third sub-mount point in the plurality of sub-mount points is mounted, and the mounting path of the third sub-mount point depends on the mounting path of the second sub-mount point.

13. The method of claim 12, wherein, Before the mounting of the plurality of sub-mount points, the method further includes: The second sub-mount point is configured in a share mode.

14. The method of any of claims 1-13, wherein, The method further includes: In response to an exit event of the first application, the first mount point is unmounted.

15. An electronic device, comprising: It includes: A processor, a memory and a display screen, the memory and the display screen are coupled with the processor, the memory is used to store computer program code, the computer program code includes computer instructions, when the processor reads the computer instructions from the memory, makes the electronic device execute the method as claimed in any one of claims 1-14.

16. A computer-readable storage medium, characterized in that, The computer readable storage medium includes a computer program, when the computer program runs on an electronic device, makes the electronic device execute the method as claimed in any one of claims 1-14.

17. A computer program product, characterised in that, When the computer program product runs on a computer, the computer executes the method as claimed in any one of claims 1-14.

Images