Mounting method and electronic equipment

Abstract

The invention provides a mounting method and electronic equipment, and relates to the technical field of terminals. According to the application, mounting of the application public file can be completed in the equipment startup process, so that only the application private file needs to be mounted in the subsequent application process incubation process, the application process incubation efficiency is improved, and the user waiting time is shortened. The method comprises: in response to a startup operation of a user, the electronic device configures a common mounting point, the common mounting point is used for mounting a common file, the common file is a resource accessed by both a first application and a second application in the electronic device, and the first application is different from the second application. In response to the starting event of the first application, the electronic device configures a first mounting point of the first application, the first mounting point is used for mounting a private file of the first application, the private file of the first application is a resource independently accessed by the first application, and the first mounting point is a sub-mounting point of the public mounting point.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a mounting method and an electronic device. Background Technology

[0002] Generally, sandboxing technology creates isolated environments for running code or applications, ensuring that their operation does not pose potential security risks to the system or other programs. Optionally, operating system sandboxes typically include three types: application process sandboxes, system process sandboxes, and chip component process sandboxes. In these sandboxes, each process can only access files within the sandbox's design scope during runtime, and cannot access the global file system, thus enhancing security.

[0003] In some examples, each application process is configured with an independent sandbox to isolate its execution and ensure application security. Therefore, during the application process incubation process, all mount points required by the sandbox need to be mounted. However, a large number of mount points can slow down the incubation process, resulting in longer user wait times and negatively impacting the user experience. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a mounting method and an electronic device. The technical solution provided by this application enables the mounting of application public files during the device startup process, thereby necessitating the mounting of application private files only during subsequent application process incubation, improving application process incubation efficiency and reducing user waiting time.

[0005] To achieve the above-mentioned technical objectives, this application provides the following technical solution:

[0006] Firstly, a mounting method is provided for an electronic device. The method includes: in response to a user's power-on operation, configuring a common mount point for mounting a common file, which is a resource accessed by both a first application and a second application in the electronic device, but the first and second applications are different; and in response to a startup event of the first application, configuring a first mount point for mounting a private file of the first application, which is a resource accessed only by the first application, and the first mount point is a sub-mount point of the common mount point.

[0007] In this way, by mounting in stages, only the application's private mount point (such as the first mount point) needs to be mounted during the application startup process, which effectively reduces the application startup time and the user's waiting time.

[0008] Furthermore, by mounting in stages, the mounting of common files for all applications is completed during the boot process of the electronic device, avoiding the repeated mounting of the same mount point during the subsequent startup of different applications.

[0009] In some examples, the first application, during its operation, needs to access resources including public resources (such as resources in public files) and private resources (such as resources in private files). Public files are mounted on public mount points, through which resources within public files can be accessed; private files are mounted on private mount points, through which resources within private files can be accessed.

[0010] According to the first aspect, the method further includes: in response to the startup event of the second application, configuring a second mount point for the second application, the second mount point being used to mount the private files of the second application, wherein the private files of the second application are resources accessed only by the second application, and the second mount point is a submount point of the public mount point.

[0011] In response to the application launch event, the application enters the incubation process and creates the application process.

[0012] In this way, different applications can configure their own private mount points based on the same public mount point during the startup process, effectively improving application incubation efficiency.

[0013] According to the first aspect, or any implementation of the first aspect above, in response to the startup event of the first application, the first mount point of the first application is configured, including: 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 file content to be added according to the public mount point. A first namespace is created. In the first namespace, the first application process mounts the first application's private files under the first mount point of the file content to be added.

[0014] In this way, before the application's unique namespace is created, the first application process can reuse public files and configure the first mount point for the files to be added. After the namespace is created, private files can be added to the first mount point, achieving namespace-based private file isolation. Furthermore, this ensures that each application process has the same directory structure within the sandbox, but the actual file content differs between applications.

[0015] According to the first aspect, or any implementation of the first aspect above, 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 the stage of configuring a common mount point before the first application starts. The second mounting stage is the stage of configuring a first mount point for the content of the file to be added during the startup of the first application. The third mounting stage is the stage of mounting the private files of the first application under the first mount point for the content of the file to be added during the startup of the first application.

[0016] For example, the first mounting phase is the public mounting phase, the second mounting phase is the mounting phase before the namespace is created, and the third mounting phase is the mounting phase after the namespace is created.

[0017] In this way, by mounting in stages, all public files of the application are mounted during the public mounting stage before the application starts, while only the application's private mount points need to be mounted during the application startup process, effectively reducing application startup time and user waiting time.

[0018] According to the first aspect, or any implementation of the first aspect above, in response to the user's boot operation, a public mount point is configured, including: in response to the user's boot operation, configuring the first public mount point in the public mount point via a share method. The method further includes: during the operation of the first application, in response to a first mount point update event, updating the first public mount point and the first sub-mount point of the first public mount point, and the first application obtaining the update results of the first public mount point and the first sub-mount point.

[0019] In some examples, mount points are configured using the share method, enabling updates to be propagated to both the mount point and its child mount points. For instance, when a mount point mounted using the share method is updated, the update will also be propagated to its child mount points, thus ensuring consistency of state between the parent and child mount points.

[0020] In this way, by defining updatable mount points, the problem of mount points being unable to be updated after being mounted is solved.

[0021] According to the first aspect, or any implementation of the first aspect above, the first mount point update event includes the first public file under the first public mount point becoming invalid or system files being updated.

[0022] According to the first aspect, or any implementation of the first aspect above, in response to the startup event of the first application, the first mount point of the first application is configured, including: in response to the startup event of the first application, configuring the third mount point of the file content to be added via a share method, wherein the first mount point includes the third mount point. The method further includes: during the operation of the first application, in response to a second mount point update event, the first application process updates the third mount point of the file content to be added, wherein the first private file is not mounted under the third mount point of the file content to be added, or the first private file is already mounted.

[0023] In this way, by defining updatable mount points, the problem of mount points being unable to be updated after being mounted is solved.

[0024] According to the first aspect, or any implementation of the first aspect above, the second mount point update event includes any of the following situations: the third mount point where the file content to be added fails to mount, an unlock event occurs and the first application is the application that was running before the unlock, the first private file becomes invalid, or the first private file is updated.

[0025] For example, if the electronic device locks its screen while the first application is running, the third mount point for the first application might fail to mount during the initial unlocking process. In this case, a second update can be automatically triggered based on the third mount point configured via the share method. This remounts the third mount point and its sub-mount points, preventing the first application from failing to function properly in subsequent updates.

[0026] According to the first aspect, or any implementation of the first aspect above, the electronic device is configured with a mount point combination, which includes multiple sub-mount points. The method further includes: mounting multiple sub-mount points when the fourth mount point meets preset conditions, wherein the fourth mount point is a common mount point or a first mount point, and the preset conditions include a first permission or a first working mode.

[0027] For example, the same mount point may need to be mounted under multiple licenses / permissions. In this case, these mount points can be combined to obtain a mount point combination. Then, this mount point combination can be added to the corresponding license / permission. Optionally, licenses / permissions can be defined using preset conditions.

[0028] For example, both public and private mount points can be mounted to corresponding combinations of mount points if preset conditions are met.

[0029] Thus, by combining and configuring mounting points, the mounting process of regular mounting points can be achieved.

[0030] According to the first aspect, or any implementation of the first aspect above, the electronic device includes a configuration file that indicates the dependency relationship of mount paths for multiple sub-mount points.

[0031] In this way, during application development, developers can directly download the configuration file and add the corresponding mount points in the application as mount dependency paths and mount paths in the configuration file. This eliminates the need to establish dependencies between different mount points individually, reducing the complexity of application development.

[0032] According to the first aspect, or any of the implementations of the first aspect above, the configuration file is also used to modify dependencies.

[0033] This reduces the difficulty of application upgrade and development.

[0034] According to the first aspect, or any implementation of the first aspect above, multiple sub-mount points are mounted, including: first mounting the second sub-mount point among the multiple sub-mount points, then mounting the third sub-mount point among the multiple sub-mount points, wherein the mounting path of the third sub-mount point depends on the mounting path of the second sub-mount point.

[0035] In this way, through predefined dependencies, the orderly mounting of multiple sub-mount points in the mount point combination can be achieved.

[0036] According to the first aspect, or any implementation of the first aspect above, before mounting multiple sub-mount points, the method further includes: configuring the second sub-mount point via a share method.

[0037] Thus, by combining mount points, duplicate mount points are categorized, thereby standardizing the mounting process. Furthermore, combined with the shared approach example above, the mount point combination mechanism enables the handling of mount points with dependencies, improving mounting efficiency.

[0038] According to the first aspect, or any implementation of the first aspect above, the method further includes: unloading the first mount point in response to the exit event of the first application.

[0039] In some examples, the exit event for the first application includes events such as responding to user actions to exit the first application or the first application exiting abnormally. Optionally, the exit event for the first application may include the termination of the application process of the first application. It should be understood that if the first application is running in the background and its process has not terminated, the first mount point will not be unmounted.

[0040] 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, while the public mount point is not unmounted. This allows other applications to subsequently mount their private mount points based on the public mount point that has not been unmounted.

[0041] In this way, in response to the exit of the first application, the electronic device can automatically unload the private mount point of the first application, terminate the operation of the first application, and realize the flexible loading and flexibility of the application's private mount point.

[0042] Secondly, an electronic device is provided. The electronic device includes a processor and a memory. The memory is coupled to the processor and stores computer program code, including computer instructions. When the processor reads the computer instructions from the memory, the electronic device executes: in response to a user's power-on operation, configuring a common mount point for mounting common files, which are resources accessed by a first application and a second application in the electronic device, the first application and the second application being different; in response to a startup event of the first application, configuring a first mount point for mounting private files of the first application, the private files being resources accessed only by the first application, the first mount point being a sub-mount point of the common mount point.

[0043] According to the second aspect, when the processor reads computer instructions from memory, it also causes the electronic device to execute: in response to a startup event of the second application, a second mount point of the second application, the second mount point being used to mount private files of the second application, wherein the private files of the second application are resources accessed only by the second application, and the second mount point is a submount point of the public mount point.

[0044] According to the second aspect, or any implementation of the second aspect above, in response to the startup event of the first application, the first mount point of the first application is configured, including: 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 file content to be added according to the public mount point. A first namespace is created. In the first namespace, the first application process mounts the first application's private files under the first mount point of the file content to be added.

[0045] According to the second aspect, or any implementation of the second aspect above, 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 the stage of configuring a common mount point before the first application starts. The second mounting stage is the stage of configuring a first mount point for the content of the file to be added during the startup of the first application. The third mounting stage is the stage of mounting the private files of the first application under the first mount point for the content of the file to be added during the startup of the first application.

[0046] According to the second aspect, or any implementation of the second aspect above, in response to a user's power-on operation, a common mount point is configured, including: in response to a user's power-on operation, configuring a first common mount point in the common mount points via a share method. When the processor reads computer instructions from memory, it also causes the electronic device to execute: during the execution of the first application, in response to a first mount point update event, updating the first common mount point and the first sub-mount point of the first common mount point, and the first application obtains the update results of the first common mount point and the first sub-mount point.

[0047] According to the second aspect, or any implementation of the second aspect above, the first mount point update event includes the first public file under the first public mount point becoming invalid or system files being updated.

[0048] According to the second aspect, or any implementation of the second aspect above, in response to the startup event of the first application, the first mount point of the first application is configured, including: in response to the startup event of the first application, configuring the third mount point of the file content to be added via a share method, wherein the first mount point includes the third mount point. When the processor reads computer instructions from memory, it also causes the electronic device to execute: during the operation of the first application, in response to the second mount point update event, the first application process updates the third mount point of the file content to be added, wherein the first private file is not mounted under the third mount point of the file content to be added, or the first private file is already mounted.

[0049] According to the second aspect, or any implementation of the second aspect above, the second mount point update event includes any of the following situations: the third mount point to which the file content to be added fails to mount, an unlock event occurs and the first application is the application that was running before the unlock, the first private file becomes invalid, or the first private file is updated.

[0050] According to the second aspect, or any implementation of the second aspect above, the electronic device is configured with a mount point combination, which includes multiple sub-mount points. When the processor reads computer instructions from the memory, it also causes the electronic device to execute: if the fourth mount point meets preset conditions, mount multiple sub-mount points, where the fourth mount point is a common mount point or a first mount point, and the preset conditions include a first permission or a first working mode.

[0051] According to the second aspect, or any implementation of the second aspect above, the electronic device includes a configuration file that indicates the dependency relationship of mount paths for multiple sub-mount points.

[0052] According to the second aspect, or any of the implementations of the second aspect above, the configuration file is also used to modify dependencies.

[0053] According to the second aspect, or any implementation of the second aspect above, multiple sub-mount points are mounted, including: first mounting the second sub-mount point among the multiple sub-mount points, then mounting the third sub-mount point among the multiple sub-mount points, wherein the mounting path of the third sub-mount point depends on the mounting path of the second sub-mount point.

[0054] According to the second aspect, or any implementation of the second aspect above, before mounting multiple sub-mount points, the method further includes: configuring the second sub-mount point via a share method.

[0055] According to the second aspect, or any implementation of the second aspect above, when the processor reads computer instructions from memory, it also causes the electronic device to perform: unmounting the first mount point in response to an exit event of the first application.

[0056] Thirdly, an electronic device is provided that has the function of implementing the method described in the first aspect and any of its possible implementations. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the described function.

[0057] Fourthly, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program (also referred to as instructions or code) that, when executed by an electronic device, causes the electronic device to perform the method of the first aspect or any embodiment of the first aspect.

[0058] Fifthly, a computer program product is provided that, when run on an electronic device, causes the electronic device to perform the method of the first aspect or any one of the embodiments of the first aspect.

[0059] In a sixth aspect, a circuit system is provided, the circuit system including processing circuitry configured to perform the method of the first aspect or any embodiment of the first aspect.

[0060] In a seventh aspect, a chip system is provided, including at least one processor and at least one interface circuit, wherein the at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor, and when the at least one processor executes the instructions, the at least one processor performs the method of the first aspect or any embodiment of the first aspect.

[0061] The technical effects of the aforementioned aspects can be referenced from each other, and will not be elaborated further here. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the global file system mount structure provided in an embodiment of this application;

[0063] Figure 2 This is a schematic diagram of the mounting process provided in an embodiment of this application;

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

[0065] Figure 4 A schematic flowchart of the mounting method provided in this application embodiment. Figure 1 ;

[0066] Figure 5This is a schematic diagram of the initial mounting relationship provided in an embodiment of this application;

[0067] Figure 6 A schematic diagram illustrating a scenario where the device updates the mount points for all applications during operation, as provided in this embodiment of the application.

[0068] Figure 7 This is a schematic diagram illustrating a scenario where some applications update their mount points during device operation, as provided in an embodiment of this application.

[0069] Figure 8 A schematic flowchart of the mounting method provided in this application embodiment. Figure 2 ;

[0070] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0071] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one or more (including two).

[0072] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0073] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0074] In some embodiments, the electronic device is configured with a global file system (GFS) to manage storage resources. GFS, as part of the operating system's file system architecture, allows access to storage resources via mount points. Optionally, a mount point is a directory within the file system that allows other file systems or devices to be mounted, making these resources accessible under that mount point.

[0075] For example, such as Figure 1 As shown, common mount points in GFS include data mount point (data), sandbox mount point (sandbox), virtual file system mount point (proc), system mount point (system), temporary mount point (mnt), device file mount point (dev), vendor file mount point (vendor), and another virtual file system mount point (sys). Among these, data is typically used to store application or user data and can be shared and accessed by multiple system nodes. Sandbox may be used for a secure sandbox environment, restricting programs to run in an isolated environment to prevent impact on other parts of the system. proc provides kernel and process information. system may be used to store system-level files and resources. mnt is used for temporarily mounting external storage devices or file systems. dev represents various hardware devices in the system, providing access interfaces to the hardware. vendor is typically used to store vendor-specific system files or drivers, and in some systems is used to distinguish components provided by third-party vendors. sys provides information interaction with the kernel and system devices, similar to proc, for device management and system status queries. These mount points help organize and manage system resources and files, ensuring the normal operation of the system and data consistency.

[0076] Each mount point can also mount other sub-mount points. For example, the sub-mount points under `system` include `lib` for storing system shared library files, `bin` for storing basic system commands and executable files, and `etc` for containing system configuration files, etc. Another example is... Figure 1As shown, the sandbox includes three types of sandboxes: application process sandbox, system component process sandbox, and chip component process sandbox. These three types of sandboxes can also mount various types of mount points, including the sandbox root directory, and read-only and writable directories mounted under the sandbox root directory. Read-only files in the read-only directory can only be read by processes, not written to. Writable files in the writable directory can be read and written by processes.

[0077] Alternatively, application process sandboxing is a technique that runs applications in an isolated environment to prevent them from harming the system or other applications. Sandboxing restricts an application's access to system resources, such as the file system, network, and processes, ensuring that even if an application contains malicious code or vulnerabilities, it will not affect the main system. System component process sandboxing is used to isolate core components and services of the operating system to improve system security and stability. It ensures that even if system components are attacked or vulnerabilities are found, there will be no widespread impact on the main system. Chip component process sandboxing (also known as hardware sandboxing or hardware isolation) is a security technology designed to isolate and protect critical functions and data within a chip to prevent malicious attacks or data breaches.

[0078] Optionally, system component process sandboxes and chip component process sandboxes can be shared by multiple processes, while application process sandboxes are configured with independent sandboxes for each application for isolation.

[0079] For example, the file system visible to each application process at runtime is actually constructed from multiple mount points, such as... Figure 1 As shown, the application process sandbox includes at least one read-only mount point and at least one writable mount point. Figure 2 As shown, the application process sandbox adopts a configurable design, separating the mounting process and mount points, thus facilitating the expansion of mount points, such as adding new mount points. During the application process incubation process, the sandbox environment of the application can be obtained based on the application incubation context and sandbox configuration file. The application incubation context includes the package name and permissions. The package name indicates the mount path of the mount points, and the permissions indicate the number of mount points. Optionally, the application process incubation process may include, for example, the application startup process, during which the corresponding application process is created, thereby achieving application process incubation.

[0080] Generally, during application incubation, the application needs to mount all required mount points. Therefore, if there are a large number of mount points, the application incubation process may be slow, resulting in longer waiting times for users.

[0081] Among these risks, mounting based on package name may lead to the impersonation of package names to obtain system data. Furthermore, if mount points have the same package name or permissions, duplicate mounting may occur, causing mount point overwriting, resulting in data loss or permission changes.

[0082] Furthermore, once the application process has finished incubating, all its mount points are already mounted. During application runtime, the application process no longer has permission to modify its own mount points. That is, the application process does not support the ability to update mount points a second time after mounting. However, in some scenarios, it may be necessary to update mount points during application runtime. For example, in scenarios involving mounting and decrypting mount points, the first mount may fail, and the lack of support for secondary mount updates may prevent the application process from accessing files under that mount point.

[0083] In response, this application provides a mounting method that can mount application public files during device startup, so that during subsequent application process incubation, only application private files need to be mounted, thereby improving application process incubation efficiency and reducing user waiting time.

[0084] Optionally, the mounting method provided in this application embodiment can be applied to electronic device 100. Optionally, electronic device 100 can be, for example, a mobile phone, tablet computer, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), wearable device, vehicle terminal, artificial intelligence (AI) device, etc. The operating system installed on electronic device 100 includes, but is not limited to, […]. Alternatively, other operating systems may be used. This application does not limit the specific type of electronic device 100 or the operating system installed on it.

[0085] For example, Figure 3 A schematic diagram of an electronic device 100 is shown.

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

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

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

[0089] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0090] The following section uses electronic device 100 as an example to describe in detail the mounting method provided in the embodiments of this application.

[0091] In some embodiments, multiple applications are installed on the electronic device. Each application can be configured with its own independent sandbox environment during operation to ensure application security. Optionally, during application process incubation, the application process completes the mounting of the required mount points. Optionally, different applications may share some common mount points. In some examples, if these common mount points are mounted first after the electronic device boots up, then it is unnecessary to repeatedly mount these common mount points during subsequent application process incubation, thereby effectively improving application process incubation efficiency.

[0092] In some examples, electronic devices can categorize mount points for each application into required mount points and conditional mount points based on their necessity. Required mount points are those that every application process needs to mount during the incubation process. Conditional mount points are those that application processes with specific permissions or operating modes need to mount during the incubation process. For example, a mount point that is only allowed to be mounted by applications with specific permissions is a conditional mount point. Another example is a mount point that is only required to be mounted by applications that have certain system features enabled (such as backup and restore). The presence of these system features can be determined by obtaining the application's incubation capability information. Yet another example is a mount point that is only required to be mounted if extended data exists during the incubation process. Extended data, for example, includes Harmony Shared Packages (HSPs).

[0093] In other examples, electronic devices can divide the mount points for each application into system-const mount points and application-variable mount points based on the variability of mount points. System-const mount points are those where the source mount path is the same for different application processes under the same user during incubation. Application-variable mount points are those where the source mount directories are different for different application processes under the same user during incubation.

[0094] In some embodiments, mandatory mount points or system-level constant mount points are mount points that all applications in the electronic device need to mount, corresponding to the application's public files. Conditional mount points or application-level variable mount points are mount points that different applications in the electronic device need to mount individually, corresponding to the application's private files.

[0095] Optionally, mount points include public mount points and private mount points. Public mount points are those that all the aforementioned applications need to mount, including mandatory mount points or system-level constant mount points. Private mount points are those that different applications need to mount individually, including conditional mount points or application-level variable mount points.

[0096] 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 during operation (such as public files), and resources that different applications need to access individually during operation (such as private files). Optionally, a mount point is a directory in GFS, such as a public mount point for directories that allow public files to be mounted, and a private mount point for directories that allow private files to be mounted.

[0097] For example, such as Figure 1 As shown, mount points in the application process sandbox include read-only mount points and writable mount points. Optionally, a common mount point that all applications need to mount is, for example, a read-only mount point, used to mount common files of all applications. Private mount points that different applications need to mount individually are, for example, writable mount points, used to mount the application's respective private files.

[0098] For example, read-only mount points include: config, which stores configuration files and settings files for applications or the system; dev, which represents various hardware devices in the system and provides access interfaces to the hardware; proc, which provides kernel and process information; system, which stores system-level files and resources; vendor, which stores vendor-specific files and libraries; and some common mount points in data, such as lib, which stores system shared library files.

[0099] For example, writable mount points include private mount points in the mount point data, such as the mount point storage used to store user data and application data.

[0100] In some embodiments, the mounting phase of mount points involved in the application process incubation process can be divided into a common mount phase (STAGE_GLOBAL) and an application-local mount phase (STAGE_APP_LOCAL). The common mount phase is used, for example, 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 phase is used, for example, to mount private mount points that different applications need to mount individually, such as conditional mount points or application-level variable mount points.

[0101] For example, in response to the electronic device powering on, it enters a common mounting phase. During this phase, the electronic device mounts mount points that all applications within the device need to mount. This way, during subsequent application process incubation, each application process only needs to mount its own required mount points, while the common mount points that all applications need to mount do not need to be mounted repeatedly, thus effectively improving application process incubation efficiency.

[0102] Optionally, the public mount point mounted during the public mount phase points to the public files of all applications in the electronic device; the private mount point mounted during the application local mount phase points to the private files of each application.

[0103] In some embodiments, as shown in Table 1 below, in response to the electronic device booting up and entering the public mount phase, a corresponding mount namespace, such as the root namespace, is created to mount the application's public files within the root namespace. The mount namespace is a type of Linux namespace used to isolate file system mount points, allowing processes 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, without affecting the file system views of the host system or other sandboxes. During the public mount phase, the root namespace is created to isolate the public mount point.

[0104] Optionally, as shown in Table 1 below, the root namespace is used to mount common mount points needed by each application once during startup. Furthermore, these common mount points do not need to be unmounted during the operation of the electronic device after startup, so that subsequent application processes can reuse them.

[0105] Table 1

[0106]

[0107] The following section provides a detailed description of each mounting stage at the mounting point.

[0108] Figure 4 This is a flowchart illustrating a mounting method provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 4 The specific order described below is a limitation. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0109] S401. In response to booting, enter the public mounting phase, and the application incubator component (appspawn) mounts the application's public files.

[0110] In some embodiments, the electronic device is configured with an application incubator component (appspawn), which is an open-source tool for dynamically creating and managing instances of applications (such as application processes) on the electronic device. For example, appspawn provides automation features to manage application processes, such as starting, stopping, and restarting them. Furthermore, appspawn minimizes the mutual interference between application processes by running them in a controlled environment (such as a sandbox environment).

[0111] In some examples, appspawn initialization is triggered in response to the device booting up. During appspawn initialization, appspawn mounts common mount points (such as required mount points and system-level constant mount points). Optionally, the common mount point corresponds to a common file shared by all applications on the device.

[0112] For example, as shown in Table 1 above, in response to the electronic device booting up and entering the public mount phase, appspawn creates a root namespace to mount the application's public files within the root namespace. Specifically, appspawn creates the root namespace to isolate public mount points.

[0113] It should be understood that step S401 is an optional step that is executed during the startup process of the electronic device. However, during the subsequent running phase after the electronic device is powered on, step S401 is no longer executed. Instead, the mounting of private files during the incubation process of each application process is completed through the following steps S402-S407.

[0114] S402, The Ability Manager Service (AMS) sends an application process incubation request to appspawn.

[0115] Application Management System (AMS) is used, for example, within an operating system or application framework to manage the lifecycle and capabilities (such as services and components) of an application. For instance, AMS can manage application startup, shutdown, and restart operations to ensure the application runs as expected. It can also register and manage various application capabilities or components, ensuring they can interact correctly. Furthermore, AMS can allocate necessary resources and permissions when the application starts, optimizing application performance and stability. Finally, AMS can obtain real-time status information for the application and its components, handle exceptions, and maintain the health of the system.

[0116] In some embodiments, in response to a user's instruction to launch an application, the electronic device triggers the Application Management System (AMS) to send an application process incubation request to appspawn, indicating that the application needs to enter the incubation phase as instructed by the user. Correspondingly, appspawn receives the application process incubation request from the AMS and obtains the application that needs to enter the incubation phase.

[0117] Optionally, the operation used to indicate the launch of an application may include, for example, the user's operation on the application icon displayed on the electronic device, the operation of launching an application by voice instruction, or the operation of the user triggering the launch of another application in one application.

[0118] S403, Create application process.

[0119] S404. Enter the mounting stage before namespace creation, and mount the file directory.

[0120] In some embodiments, in response to an application process incubation request, appspawn creates a new application process, which is the process corresponding to the application currently incubating.

[0121] In some examples, `appspawn` spawns a child process (such as the application process) from an existing process using the `fork` function. The `fork` function can be used to create a new process (such as a child process) that is almost identical to the existing process. The child process starts execution from the parent process's current location but has its own independent address space. Optionally, the existing process could be, for example, the process that has already mounted the application's public files (such as the `appspawn` process). In this way, after the application process is created, it can directly reuse the already mounted public files and continue executing the subsequent private file mounting process after those public files.

[0122] In some embodiments, after forking an application process, appspawn can also mount the file directories corresponding to that application process to reuse already mounted public files. Optionally, the file directories mounted by appspawn may point to public files that have already been mounted. Optionally, the file directories mounted by appspawn may also include file directories corresponding to private files, but these file directories do not currently have any files mounted and need to be mounted through step S405 below. For example, after the application process is created, appspawn can obtain the file directories corresponding to all files required during the current application's operation. These file directories include file directories corresponding to public files and file directories corresponding to private files, where the public files have already been mounted through step S401 above.

[0123] In this way, by creating a child process fork, the common mount point can be reused, avoiding the problem of the same mount point being mounted multiple times in different applications.

[0124] In some embodiments, as described above, sandbox environment isolation between different application processes is achieved by using a mount namespace. In such cases, appspawn can create a new mount namespace to mount the application's private mount point.

[0125] In some examples, before creating a new mount namespace, appspawn can obtain the application's file directory, mount capabilities, and other information based on the application's configuration file. Optionally, mount capabilities may include mount point propagation capabilities and mount point re-update capabilities. The mount point propagation capability indicates whether the application process has the ability to copy public mount points and to subsequently mount private mount points based on public mount points. The mount point re-update capability indicates whether the mount point has the ability to update the mount point; details of the mount point re-update capability are described in the relevant embodiments below and will not be repeated here.

[0126] In some examples, as shown in Table 1 above, the mounting phase before creating a new namespace is, for example, the mounting phase before namespace creation (STAGE_PRE_UNSHARE). In STAGE_PRE_UNSHARE, appspawn mounts application-differentiated mount points in the root namespace; these mount points are those that operate in conjunction with the root namespace process.

[0127] For example, as described above, the data mount point includes some public mount points (such as the mount point lib) and some private mount points (such as the mount point storage). Then, in STAGE_PRE_UNSHARE, appspawn can mount the file directories corresponding to these private mount points in the root namespace. Subsequently, after the application process completes the creation of the new namespace, it can mount the required private files in the file directories corresponding to these private mount points, making the directory structure the same for each application process within the sandbox, but the actual file content different for each application. For example, appspawn can mount an empty storage. Or, appspawn can mount multiple empty sub-mount points under storage. Subsequently, the application process can mount private files under the empty mount points (see step S405 below for details).

[0128] In some examples, as shown in Table 1 above, during the application exit process, appspawn can unload the content mounted on STAGE_PRE_UNSHARE, thus enabling appspawn to manage the application process.

[0129] Optionally, the application process can also mount the file directory after creation. That is, the process of mounting the file directory using appspawn in the above embodiments can also be implemented by the application process.

[0130] S405. Create a namespace and enter the mounting stage after the namespace is created. Mount the application's private files in the file directory.

[0131] In some embodiments, `appspawn` uses the `unshare` command to create new namespaces, such as application namespaces. The `unshare` command is a Linux command that allows a program to isolate certain resources of its process while it is running, creating new namespaces. For example, the `unshare` command can be used to isolate file systems, process IDs, or network resources.

[0132] Optionally, in STAGE_PRE_UNSHARE, appspawn obtains that the application has mount point passing capabilities, which can trigger the creation of a new namespace to mount private files in that new namespace.

[0133] In some embodiments, as shown in Table 1 above, after a namespace is created, the application process can enter the mounting phase (STAGE_POST_UNSHARE). Optionally, in STAGE_POST_UNSHARE, the application process can mount application-specific mount points in the appnamespace, such as the application process's private mount points.

[0134] In some embodiments, under STAGE_POST_UNSHARE, the application process can use the Pivot root function to change the root file system of the current process to another file system to achieve different root file system mounting.

[0135] For example, an application process creates a new namespace using the `unshare` command, which contains a copy of the already mounted public mount point. The application process can then use the `Pivot root` function to mount private mount points based on the public mount point. For instance, the public mount point might include a `data` mount point, under which a public mount point `lib` is mounted, along with a private mount point `storage`. The application process can obtain the file directory mounted in `STAGE_PRE_UNSHARE`, which contains the mount structure relationships of each mount point. The application process can then use the `Pivot root` function to modify the private mount point `storage` in the file directory to mount the application's private mount points under that private mount point. These private mount points can point to the application's private files.

[0136] STAGE_POST_UNSHARE can also be described as the application local mount stage (STAGE_APP_LOCAL), which is used to mount the application's private files in the application's unique app namespace.

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

[0138] S406. The application process sends a mount completion indication to appspawn.

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

[0140] In some embodiments, after the application process completes mounting the private mount points, it can send a mount completion indication to appspawn, indicating that appspawn has now completed mounting all mount points. Accordingly, appspawn determines that all mount points have been successfully mounted based on the received mount completion indication from the application process. Then, appspawn can send an application process incubation completion response to AMS. Accordingly, AMS determines that the application process has completed incubation based on the received application process incubation completion response. The electronic device can then launch the application normally and display the corresponding application interface.

[0141] In this way, by mounting in stages, only the application's private mount point needs to be mounted during the application process incubation, effectively reducing the application process incubation time and user waiting time.

[0142] Furthermore, by mounting in stages, the system avoids different applications repeatedly mounting the same mount point.

[0143] Furthermore, by mounting in stages, it is possible to mount private mount points based on conditions such as permissions, incubation capability bits, or extended data, thereby enhancing the scalability of application process mounting.

[0144] In some embodiments, during the initial incubation process, the application can complete the mounting of private mount points before creating the namespace via unshare. Subsequently, during the application's re-incubation process, all already incubated mount points can be reused without any mounting time consumption, further improving application incubation efficiency.

[0145] In some scenarios, after an application process has finished incubating, all of its mount points have already been mounted. Furthermore, during application execution, the application process does not have permission to modify its own mount points. Therefore, in some cases, the inability to update mount points may cause the application process to malfunction.

[0146] Optionally, in a preset scenario, the electronic device may need to update the mount point. Optionally, the preset scenario may include, for example, a scenario where mounting a file under a certain mount point failed during the previous mounting process, or a scenario where a file mounted under a certain mount point became invalid. File invalidation includes, for example, the existence of an updated version of the file.

[0147] For example, if an application was already running before the screen was locked, meaning all mount points had been mounted, and then the electronic device locks the screen (this application also ran before the screen was locked), data under some private mount points might also be locked. Later, when the electronic device unlocks, the first attempt to mount these private mount points might fail, potentially requiring remounting. However, due to the restriction that application processes cannot modify their own mount points, they cannot directly remount these private mount points. For instance, mount point `data` mounts a private mount point `storage`, which in turn mounts a mount point `el2`. This mount point can be used to store group information related to user authentication and authorization. Therefore, after the electronic device unlocks, the decrypted mount point `el2` needs to be remounted.

[0148] For example, after the nweb framework is upgraded, each application process needs to update the nweb resource directory mount point. Obviously, these application processes include those that have already been incubated. The nweb framework is a lightweight web framework, typically used in embedded systems or resource-isolated environments to provide basic web server functionality, static file services, etc.

[0149] Therefore, this application provides a mounting method that enables secondary updates of the mount point. The secondary update process of the mount point is described in detail below.

[0150] In some embodiments, a mount point that can be updated during the running of the application process is called an updatable mount point.

[0151] In some embodiments, by creating an MS_SHARED root mount point for an updatable mount point, the corresponding updatable can be updated during the application process.

[0152] Optionally, the `shared` mount option is used to set the shared attributes of a mount point. For example, the `shared` mount option can control the visibility and transitivity of a mount point among its child mount points. If a new mount point is created under a `shared` mount point, changes to these new mount points will also be propagated to this shared mount point, thus ensuring consistency of state between the parent and child mount points.

[0153] For example, the system service process updates the updatable mount point under the MS_SHARED mount point in the root namespace, enabling mount point updates during application process execution. Optionally, the MS_SHARED mount point is referred to as the updatable root mount point.

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

[0155] In some embodiments, during the STAGE_PRE_UNSHARE process of appspawn mounting the file directory, it can be determined whether the mount point in the file directory has the capability for secondary mount point updates. Optionally, the mount point with the capability for secondary mount point updates can be set as the updatable-root mount point. This way, when a secondary update is required, the updatable mount point mounted under this updatable-root mount point can be updated.

[0156] In some embodiments, the update scenarios for updatable mount points include secondary update scenarios for common mount points and secondary update scenarios for mount points of some applications. Secondary update scenarios for common mount points include, for example, secondary updates for required mount points and secondary updates for system-const mount points. Secondary update scenarios for mount points of some applications include, for example, secondary updates for conditional mount points or secondary updates for application-variable mount points.

[0157] Optionally, for scenarios involving secondary updates of mount points for certain applications, the mount points for those applications can be unmounted during the exit process of those applications, including the updatable-root mount point and the updatable mount point.

[0158] For example, such as Figure 5 As shown, in STAGE_GLOBAL, the application public files mounted by appspawn include application public file A and application public file B. In STAGE_PRE_UNSHARE, the file directories mounted by appspawn include the private file directory of application 1 and the private file directory of application 2. Subsequently, after appspawn creates the application process and namespace, the application process corresponding to application 1 can mount private files in the private file directory of application 1, such as private file 1 and private file 2 of application 1. In this way, the application process corresponding to application 1 can obtain all the mount points of application 1 that have been successfully mounted. Similarly, the application process corresponding to application 2 can mount private files in the private file directory of application 2, such as private file 1 and private file 2 of application 2. In this way, the application process corresponding to application 2 can obtain all the mount points of application 2 that have been successfully mounted. The above process is the initial mount relationship establishment process.

[0159] based on Figure 5 In the example initial mount relationship, for scenarios involving secondary updates of the common mount point, the required common mount point can be configured using the MS_SHARED method during the initial mount relationship establishment process. This way, during the secondary update process, system processes (such as the appspawn process) can update the child mount points (such as the updatable mount point) mounted under that MS_SHARED in the root namespace. For example, as shown... Figure 6As shown, during the initial mount point establishment process, appspawn configures the mount point corresponding to the application's common file B using the MS_SHARED method. Then, during the operation of the electronic device, the system process can update the mount point corresponding to the application's common file B in the root namespace. Consequently, the sub-mount points mounted under the mount point corresponding to the application's common file B are also updated, such as the mount point corresponding to the common file C. Therefore, based on the established initial mount point relationship, the mount points corresponding to the application's common file B and the common file C in the application processes corresponding to application 1 and application 2, which have already completed incubation, will also be updated accordingly.

[0160] based on Figure 5 The example initial mount relationship, for scenarios involving secondary updates of mount points in some applications, can be configured with the required private mount points via MS_SHARED during the initial mount relationship establishment process. This way, during secondary updates, the application process can update the sub-mount points (such as the updatable mount point) mounted under that MS_SHARED in the corresponding app namespace. For example, as shown... Figure 7 As shown, during the initial mount relationship establishment process, `appspawn` configures the file directory of application 2 to include `MS_SHARED`, such as configuring the mount point corresponding to the private file 2 of application 2 using the `MS_SHARED` method. Then, during the operation of the electronic device, the application process corresponding to application 2 can update the mount point corresponding to the private file 2 of application 2 in the appnamespace of application 2 based on the file directory. The sub-mount points mounted under the mount point corresponding to the private file 2 are also updated accordingly, such as the mount point corresponding to the private file D. Furthermore, this secondary update of the mount point corresponding to the private file of application 2 does not affect the mount point in the currently running application 1.

[0161] In this way, by defining updatable mount points, the problem of mount points being unable to be updated after mounting is solved. Furthermore, managing the mounting process in stages achieves better management results.

[0162] The following section uses the secondary update process of the el2 mount point as an example to provide a detailed explanation of the secondary update process of the mount point.

[0163] For example, in step S404 above, in response to the application incubation request, during STAGE_PRE_UNSHARE, appspawn creates application process A and mounts the el2 mount point in MS_SHARED mode, such as mounting an empty el2 source directory for the application's el2 directory. After application process A has finished incubating, if the electronic device locks its screen and then detects an unlock operation, AMS can obtain this unlock operation and send an unlock notification to appspawn. In response to this unlock notification, appspawn obtains application process A that was running before the screen was locked and the el2 source directory mounted in MS_SHARED mode in the file directory mounted by application process A. Then, appspawn can mount the corresponding private files in the el2 source directory, enabling the application process to update the mount point during runtime. Subsequently, during the application exit process corresponding to application process A, appspawn can unmount the mount point corresponding to application process A, including the el2 mount point and any sub-mount points mounted under the el2 mount point.

[0164] The previous section introduced the various mounting stages in the application incubation process and the mount points that can be updated. The following section provides a detailed introduction to the combined mounting scenarios of mount points with the same permissions.

[0165] In some embodiments, the same mount point needs to be mounted under multiple permissions. In this case, these mount points can be grouped together to obtain a MountPointGroup. Then, this mountpoint group is added to the corresponding permission. For example, if multiple mount points all need to mount the el2 mount point, the el2 mount point can be added to the mountpoint group, and this mountpoint group can be added to the multiple mount points that need to mount the el2 mount point. In this way, the MountPointGroup configuration scheme organizes the mounting process of mount points.

[0166] Optionally, mount point combinations can be defined under the named-groups field to combine multiple mount points of the same type.

[0167] In some embodiments, there are temporal dependencies between different mount points. For example, the temporal dependencies between mount points data, storage, and el2 are as follows: mount point data is the parent mount point of mount point storage, and mount point storage depends on mount point data in terms of temporal dependency; mount point storage is also the parent mount point of mount point el2, and mount point el2 depends on mount point storage in terms of temporal dependency.

[0168] Optionally, a named-group can be defined based on the temporal dependencies between different mount points. The named-group includes mount dependency paths (mount-paths-deps) and mount paths (mount-paths). Mount points that are depended upon are defined through mount-paths-deps; after mount-paths-deps are mounted, the mount points under mount-paths are then mounted.

[0169] For example, if mount point 1 and mount point 2 in an application both need to mount mount points A and B under the same permission, then mount points A and B can be configured into a named-group, and this named-group can be configured as `mount-paths`. Mount point 1 can be configured as the corresponding `mount-paths-deps`, and mount point 2 as the corresponding `mount-paths-deps`. This eliminates the need to separately configure the child mount points of mount point 1 (including mount points A and B) and the child mount points of mount point 2 (including mount points A and B), reducing redundant configuration. Instead, by leveraging the timing relationship between `mount-paths-deps` and `mount-paths`, the same named-group can be reused, allowing both mount points 1 and 2 to mount mount points A and B within the named-group, improving configuration efficiency.

[0170] For example, if mount points A and B in both Application 1 and Application 2 require mounting under the same permission, then mount points A and B can be configured into a named-group, and this named-group can be configured as `mount-paths`. The corresponding mount points in Application 1 and Application 2 can then be configured as `mount-paths-deps`. This way, by reusing named-groups, configuration efficiency can be improved while still meeting configuration requirements.

[0171] In some embodiments, during application development, developers can create named-group relationships between different mount points, thereby enabling the sequential mounting of multiple mount points in the named-group during the application incubation process after the application is installed on the electronic device.

[0172] In other embodiments, a pre-configured template file, such as a configuration file, is used to define named groups and the mount-paths-deps and mount-paths within those named groups. During application development, developers can directly download this configuration file and add the corresponding mount points in their application as mount-paths-deps or mount-paths within the configuration file. This eliminates the need to establish named-group relationships between different mount points individually, reducing the complexity of application development.

[0173] In some examples, when an application needs to add certain features (or be described as capabilities), it is not necessary to modify the application source code. Instead, these features can be added directly by modifying the dependencies indicated in the named-group in the configuration file. This reduces the difficulty of application upgrades and development.

[0174] In some embodiments, based on the above description of the mount point secondary update scenario, mount-paths-deps can be configured using MS_SHARED. This allows the named-group to be updated by specifying a name after the application process has finished incubating.

[0175] For example, taking the configuration of mount point el2 as mount-paths-deps using MS_SHARED as an example, the configuration process of named-group is introduced. Table 2 below explains the meaning of each field in the code used to configure named-group. R / O indicates that the current field is either required or optional. A string field indicates that it is used to store text data. A MountPath field indicates that it is used to indicate the mount path. It can be seen that by defining mount point el2 as mount-paths-deps and configuring it using MS_SHARED, the ordered mounting of mount point el2 and its child mount points is achieved. Furthermore, secondary updates of mount point el2 and its child mount points are implemented.

[0176] {

[0177] "name":"el2",

[0178] "type":"app-variable",

[0179] "deps-mode":"always|not-exist"

[0180] "mount-paths-deps":{

[0181] "sandbox-path":" / data / app / el2",

[0182] "src-path":" / mnt / sandbox / <currentuserid> / app_variable / el2 / <packagename>",

[0183] "category":"shared"

[0184] },

[0185] "mount-paths":[{...}

[0186] }

[0187] Table 2

[0188]

[0189] Thus, the named-group mechanism categorizes duplicate mount points, thereby standardizing the mounting process. Furthermore, combined with the MS_SHARED example above, the named-group mechanism handles mount points with dependencies, improving mounting efficiency.

[0190] Furthermore, through phased mounting and the named-group mechanism, during the application incubation process, it is no longer necessary to rely solely on the package name to configure the mount point. This avoids the security risks of impersonating the package name to obtain system data, as well as the possibility of duplicate mounting of mount points with the same package name or permissions, which could lead to mount point overwriting, data loss, or permission changes.

[0191] Figure 8 This is a flowchart illustrating a mounting method provided in an embodiment of this application. It should be noted that this method does not rely on... Figure 8 The specific order described below is a limitation. It should be understood that in other embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0192] S801, In response to the user's power-on operation, the electronic device is configured with a common mount point.

[0193] This public mount point is used to mount public files of applications on the electronic device. These public files are resources that all applications on the electronic device need to access. For example, if the electronic device has a first application and a second application installed, then both the first and second applications need to access the resources in this public file during their operation.

[0194] In some embodiments, mount points include public mount points and private mount points. Public mount points are those that all applications need to mount, such as mandatory mount points or system-level constant mount points. Private mount points are those that different applications need to mount individually, such as conditional mount points or application-level variable mount points. Optionally, public mount points point to common files shared by all applications in the electronic device; private mount points point to private files of each application.

[0195] In some embodiments, in response to the electronic device being powered on, the electronic device mounting triggers the entry into the common mounting phase, creates a root namespace, and configures a common mount point in the root namespace to mount common files of all applications included in the current electronic device.

[0196] In this way, by mounting in stages, the mounting of public files is completed during the device startup phase. During the subsequent application incubation process, it is not necessary to mount these public files again, effectively reducing the mounting pressure during the application incubation process.

[0197] In some embodiments, in a preset scenario, it may be necessary to update the mount point, i.e., to configure the mount point's secondary update capability. Optionally, a mount point that can be updated during application process execution is called an updatable mount point.

[0198] Optionally, the preset scenarios include scenarios such as a file mounting failure at a certain mount point during the previous mounting process, or a file mounted at a certain mount point becoming invalid. File invalidation includes, for example, the existence of an updated version of the file.

[0199] In some examples, mount points are configured using the share method, enabling updates to be propagated to both the mount point and its child mount points. For instance, when a mount point mounted using the share method is updated, the update will also be propagated to its child mount points, thus ensuring consistency of state between the parent and child mount points.

[0200] In some examples, the mount point configured using the share method can be either a public mount point or a private mount point.

[0201] Optionally, in response to a user's boot operation, a public mount point is configured, including: in response to a user's boot operation, configuring the first public mount point in the public mount point via a share method. Subsequently, during the operation of the first application, in response to a first mount point update event, the first public mount point and the first sub-mount point of the first public mount point are updated, and the first application obtains the update results of the first public mount point and the first sub-mount point.

[0202] Among them, the first mount point update event includes the first public file under the first public mount point becoming invalid or system files being updated.

[0203] For example, during the power-on phase of an electronic device, the device configures a first public mount point via a share method, which points to a first public file. Subsequently, during the device's operation, this first public file may become invalid. For instance, after an upgrade of the nweb framework, some system files will be updated, rendering the corresponding original system files invalid. In this case, the electronic device needs to update the first public mount point corresponding to the first public file. After the first public mount point is updated via the share method, the first sub-mount point of the first public mount point will also be updated accordingly. The first application currently running has already mounted the first public mount point. Therefore, in this scenario, the first application can directly and synchronously obtain the update results of both the first public mount point and the first sub-mount point.

[0204] For example, such as Figure 6 As shown, during the initial mount point establishment process, appspawn configures the mount point corresponding to the application's common file B using MS_SHARED. Then, during the operation of the electronic device, the system process can update the mount point corresponding to the application's common file B in the root namespace. Consequently, the sub-mount points mounted under the mount point corresponding to the application's common file B are also updated, such as the mount point corresponding to the common file C. Therefore, based on the established initial mount point relationship, the mount points corresponding to the application's common file B and common file C in the application processes corresponding to Application 1 and Application 2, which have already completed incubation, will also be updated accordingly.

[0205] In this way, by defining updatable mount points, the problem of mount points being unable to be updated after being mounted is solved.

[0206] S802, In response to the startup event of the first application, the electronic device configures the first mount point of the first application.

[0207] The first mount point is used to mount the private files of the first application. These private files are resources that the first application needs to access independently. The first mount point is a sub-mount point of the public mount point. For example, during operation, the first application needs to access both public resources (such as resources in public files) and private resources (such as resources in private files). Public files are mounted on the public mount point, allowing access to resources within public files. Private files are mounted on the private mount point, allowing access to resources within private files.

[0208] In some embodiments, in response to a startup event of the first application, a first application process corresponding to the first application is created, and a first mount point for the file content to be added is configured according to a public mount point. Then, the electronic device creates a first namespace. In the first namespace, the first application process mounts the first application's private files under the first mount point for the file content to be added.

[0209] Optionally, the mounting phase of the first application includes a first mounting phase, a second mounting phase, and a third mounting phase. The first mounting phase is the phase of configuring a common mount point before the first application starts. The second mounting phase is the phase of configuring a first mount point for the content of the file to be added during the startup of the first application. The third mounting phase is the phase of mounting the private files of the first application under the first mount point for the content of the file to be added during the startup of the first application.

[0210] For example, as shown in Table 1 above, the first mounting phase is the public mounting phase (STAGE_GLOBAL), the second mounting phase is the mounting phase before namespace creation (STAGE_PRE_UNSHARE), and the third mounting phase is the mounting phase after namespace creation (STAGE_POST_UNSHARE).

[0211] In step S801, the electronic device, responding to device startup, enters the first mounting stage, completing the mounting of the common mount point. Subsequently, in step S802, in response to the startup event of the first application, it enters the second mounting stage, where appspawn creates the first application process. After creation, the first application process can directly reuse the already mounted common files. Optionally, in the second mounting stage, appspawn mounts the file directories corresponding to the first application process. Based on the reuse of common files, these file directories include directories pointing to common files (i.e., common mount points) and directories that should point to the first application's private files (i.e., private mount points). It should be understood that in the second mounting stage, since the first application's private files have not yet been mounted, the file directories that should point to the first application's private files are empty; that is, the file directory exists but is blank. Afterward, appspawn creates the namespace corresponding to the first application process, entering the third mounting stage. In the third mounting stage, the first application process can mount the first application's private files in the empty file directories, thus completing the mounting of all mount points for the first application.

[0212] In this way, by mounting in stages, only the application's private mount point needs to be mounted during the application process incubation, effectively reducing the application process incubation time and user waiting time.

[0213] Furthermore, by mounting in stages, the mounting of all common files of all applications is completed in the public mounting stage, avoiding the repeated mounting of the same mount point during the subsequent incubation process of different applications.

[0214] In some embodiments, as described in step S801 above, the mount point configured via the share method can be either a public mount point or a private mount point. Therefore, during the incubation process of the first application process, the private mount point of the first application can also be configured via the share method to enable secondary updates of that mount point.

[0215] In some examples, in response to the startup event of the first application, the first application process configures a third mount point for the file content to be added via a share method. The first mount point includes the third mount point. Subsequently, during the operation of the first application, in response to a second mount point update event, the first application process updates the third mount point for the file content to be added. This third mount point for the file content to be added either does not have the first private file mounted, or it already has the first private file mounted.

[0216] Optionally, the second mount point update event includes any of the following: the third mount point where the file content to be added fails to mount, an unlock event occurs and the first application is the application that was running before the unlock, the first private file becomes invalid, or the first private file is updated.

[0217] For example, if the electronic device locks its screen while the first application is running, the third mount point for the first application might fail to mount during the initial unlocking process. In this case, a second update can be automatically triggered based on the third mount point configured via the share method. This remounts the third mount point and its sub-mount points, preventing the first application from failing to function properly in subsequent updates.

[0218] For example, a third mount point in the running first application may already be mounted, but the first private file pointed to by the third mount point may be invalid or updated. In this case, a second update can be automatically triggered based on the third mount point configured via the share method. This will remount the third mount point and its child mount points, preventing the first application from failing to function properly in the future.

[0219] For example, such as Figure 7 As shown, during the initial mount relationship establishment process, `appspawn` configures the file directory of application 2 to include `MS_SHARED`, such as configuring the mount point corresponding to the private file 2 of application 2 using the `MS_SHARED` method. Then, during the operation of the electronic device, the application process corresponding to application 2 can update the mount point corresponding to the private file 2 of application 2 in the app namespace of application 2 based on the file directory. The sub-mount points mounted under the mount point corresponding to the private file 2 are also updated accordingly, such as the mount point corresponding to the private file D. Furthermore, this secondary update of the mount point corresponding to the private file of application 2 does not affect the mount point in the currently running application 1.

[0220] In this way, by defining updatable mount points, the problem of mount points being unable to be updated after being mounted is solved.

[0221] In some embodiments, in response to the launch event of the second application, a second mount point for the second application is configured. This second mount point is used to mount the private files of the second application, where the first and second applications are different applications, the private files of the second application are resources accessed exclusively by the second application, and the second mount point is a sub-mount point of the public mount point. It should be understood that during the incubation process of the first application, the public mount point is copied via a fork, and a sub-mount point (such as the first mount point) is created in the namespace of the first application based on the copied public mount point. Similarly, during the incubation process of the second application, the public mount point is copied via a fork, and a sub-mount point (such as the second mount point) is created in the namespace of the second application based on the copied public mount point.

[0222] In this way, different applications can configure their own private mount points based on the same public mount point during the incubation process, effectively improving the efficiency of application incubation.

[0223] In some embodiments, the electronic device is configured with a mount point combination, which includes multiple sub-mount points. When a fourth mount point meets preset conditions, the electronic device mounts multiple sub-mount points. The fourth mount point is either a common mount point or a first mount point, and the preset conditions include a first permission or a first operating mode.

[0224] For example, the same mount point may need to be mounted under multiple permissions. In this case, these mount points can be combined to obtain a mount point combination. Then, this mount point combination is added to the corresponding permission. Optionally, permissions can be defined by preset conditions. That is, a fourth mount point that meets the first permission, or a fourth mount point in the first working mode, can mount the aforementioned mount point combination.

[0225] For example, both public and private mount points can be mounted to corresponding combinations of mount points if preset conditions are met.

[0226] In this way, the mechanism of combining mount points can be used to classify duplicate mount points, thereby standardizing the mounting process.

[0227] In some embodiments, the electronic device includes a configuration file that indicates the dependencies of mount paths for multiple sub-mount points.

[0228] In this way, during application development, developers can directly download the configuration file and add the corresponding mount points in the application as mount dependency paths (mount-paths-deps) and mount paths (mount-paths) in the configuration file. This eliminates the need to establish dependencies between different mount points individually, reducing the complexity of application development.

[0229] In some examples, configuration files are also used to modify dependencies.

[0230] For example, if an application needs to add certain features (or be described as capabilities), it is not necessary to modify the application source code. Instead, these features can be added directly by modifying the dependencies indicated in the mount point combination in the configuration file.

[0231] This reduces the difficulty of application upgrade and development.

[0232] In some embodiments, an electronic device may mount multiple sub-mount points, including: first mounting a second sub-mount point from the multiple sub-mount points, and then mounting a third sub-mount point from the multiple sub-mount points. The mounting path of the third sub-mount point depends on the mounting path of the second sub-mount point.

[0233] In this way, through predefined dependencies, the orderly mounting of multiple sub-mount points in the mount point combination can be achieved.

[0234] In some examples, the second submount point is configured using the share method.

[0235] Thus, by combining mount points, duplicate mount points are categorized, thereby standardizing the mounting process. Furthermore, combined with the shared approach example above, the mount point combination mechanism enables the handling of mount points with dependencies, improving mounting efficiency.

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

[0237] In some examples, the exit event for the first application includes events such as responding to a user action to exit the first application or the first application exiting abnormally. Optionally, the exit event for the first application may include the termination of the application process of the first application. It should be understood that if the first application is running in the background and its process has not terminated, the electronic device will not unmount the first mount point.

[0238] In some examples, in response to the exit event of the first application, the electronic device only unmounts the private mount point of that first application, such as the first mount point, and does not unmount the public mount point. This allows the electronic device to subsequently mount the private mount points of other applications based on the public mount point that has not been unmounted during the startup of other applications.

[0239] In this way, in response to the exit of the first application, the electronic device can automatically unload the private mount point of the first application, terminate the operation of the first application, and realize the flexible loading and flexibility of the application's private mount point.

[0240] The above combination Figures 4-8 The mounting method provided in the embodiments of this application is described in detail below. Figure 9 This application provides a detailed description of the electronic device provided in its embodiments.

[0241] In one possible design, Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device 900 may 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.

[0242] Optionally, the transceiver unit 901 is used to receive user operations, for example, to support the electronic device 900 in performing operations. Figure 4 S401 in; and / or, for supporting electronic device 900 to perform Figure 8 S801 in the middle.

[0243] Optionally, the processing unit 902 is used to support the electronic device 900 in performing [operations]. Figure 4 S401-S407; and / or, for supporting electronic device 900 to perform Figure 8 S801 and S802 in the example.

[0244] The transceiver unit may include a receiving unit and a transmitting unit, and may be implemented by a transceiver or transceiver-related circuit components, and may be a transceiver or transceiver module. The operation and / or function of each unit in the electronic device 900 are respectively to implement the corresponding process of the mounting method described in the above method embodiments. All relevant content of each step involved in the above method embodiments can be referred to the functional description of the corresponding functional unit, and for the sake of brevity, it will not be repeated here.

[0245] Optionally, Figure 9 The electronic device 900 shown may also include a storage unit ( Figure 9 (not shown in the image), this storage unit stores a program or instruction. When the transceiver unit 901 and the processing unit 902 execute the program or instruction, it causes... Figure 9 The electronic device 900 shown can perform the mounting method described in the above method embodiments.

[0246] Figure 9 The technical effects of the electronic device 900 shown can be referred to the technical effects of the mounting method described in the above method embodiments, and will not be repeated here.

[0247] In addition to being in the form of an electronic device 900, the technical solution provided in this application can also be a functional unit or chip in an electronic device, or a device used in conjunction with an electronic device.

[0248] This application also provides a chip system, including: a processor coupled to a memory, the memory being used to store programs or instructions, which, when executed by the processor, cause the chip system to implement the methods in any of the above method embodiments.

[0249] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0250] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

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

[0252] It should be understood that each step in the above method embodiments can be completed by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0253] This application also provides a computer-readable storage medium storing a computer program. When the computer program is run on a computer, it causes the computer to perform the aforementioned steps to implement the mounting method in the above embodiments.

[0254] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the mounting method described in the above embodiments.

[0255] Additionally, this application also provides an apparatus. Specifically, the apparatus may be a component or module, and may include one or more processors and a memory connected together. The memory stores a computer program. When the computer program is executed by one or more processors, the apparatus performs the mounting methods described in the above-described method embodiments.

[0256] The apparatus, computer-readable storage medium, computer program product, or chip provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0257] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0258] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, the division of the above functional modules is only used as an example. In practical applications, the above functions can be assigned to different functional modules as needed; that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical functional division, and there may be other division methods in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of modules or units may be electrical, mechanical or other forms.

[0260] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0261] Computer-readable storage media include, but are not limited to, any of the following: USB flash drive, external hard drive, ROM, RAM, magnetic disk or optical disk, and other media capable of storing program code.

[0262] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / packagename> < / currentuserid>

Claims

1. A mounting method, characterized in that, Applied to electronic devices, the method includes: In response to the user's power-on operation, a common mount point is configured. The common mount point is used to mount common files. The common files are resources accessed by both a first application and a second application in the electronic device. The first application and the second application are different. In response to the startup event of the first application, a first mount point of the first application is configured. The first mount point is used to mount the private files of the first application. The private files of the first application are resources that the first application accesses alone. The first mount point is a sub-mount point of the public mount point.

2. The method according to claim 1, characterized in that, The method further includes: In response to the launch event of the second application, a second mount point for the second application is configured. The second mount point is used to mount the private files of the second application, wherein the private files of the second application are resources accessed exclusively by the second application, and the second mount point is a sub-mount point of the public mount point.

3. The method according to claim 1 or 2, characterized in that, The step of configuring the first mount point of the first application in response to the startup event of the first application includes: In response to the startup event of the first application, a first application process corresponding to the first application is created, and the first mount point for the file content to be added is configured according to the public mount point; Create the first namespace; In the first namespace, the first application process mounts the first application's private files under the first mount point of the file content to be added.

4. The method according to claim 3, characterized in that, The mounting phase of the first application includes a first mounting phase, a second mounting phase, and a third mounting phase. The first mounting phase is the phase of configuring the public mount point before the first application starts. The second mounting phase is the phase of configuring the first mount point of the file content to be added during the startup of the first application. The third mounting phase is the phase of mounting the private files of the first application under the first mount point of the file content to be added during the startup of the first application.

5. The method according to any one of claims 1-4, characterized in that, The configuration of a common mount point in response to a user's power-on operation includes: In response to the user's power-on operation, the first public mount point in the public mount points is configured via the share method; The method further includes: During the operation of the first application, in response to the first mount point update event, the first common mount point and the first sub-mount point of the first common mount point are updated, and the first application obtains the update results of the first common mount point and the first sub-mount point.

6. The method according to claim 5, characterized in that, The first mount point update event includes the first public file under the first public mount point becoming invalid or system files being updated.

7. The method according to any one of claims 1-6, characterized in that, The step of configuring the first mount point of the first application in response to the startup event of the first application includes: In response to the startup event of the first application, a third mount point for the file content to be added is configured via a share method, wherein the first mount point includes the third mount point; The method further includes: During the operation of the first application, in response to the second mount point update event, the first application process updates the third mount point of the file content to be added, where the first private file is either not mounted under the third mount point of the file content to be added, or the first private file has already been mounted.

8. The method according to claim 7, characterized in that, The second mount point update event includes any of the following: the third mount point for the file content to be added fails to mount, an unlock event occurs and the first application is the application that was running before the unlock, the first private file becomes invalid, or the first private file is updated.

9. The method according to any one of claims 1-8, characterized in that, The electronic device is configured with a mount point combination, which includes multiple sub-mount points; the method further includes: If the fourth mount point meets the preset conditions, the plurality of sub-mount points are mounted. The fourth mount point is either a common mount point or the first mount point. The preset conditions include a first permission or a first working mode.

10. The method according to claim 9, characterized in that, The electronic device includes a configuration file that indicates the dependency relationship of the mount paths of the plurality of sub-mount points.

11. The method according to claim 10, characterized in that, The configuration file is also used to modify the dependencies.

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

13. The method according to claim 12, characterized in that, Before mounting the plurality of sub-mount points, the method further includes: Configure the second sub-mount point using the share method.

14. The method according to any one of claims 1-13, characterized in that, The method further includes: In response to the exit event of the first application, the first mount point is unmounted.

15. An electronic device, characterized in that, include: The electronic device includes a processor, a memory, and a display screen, the memory and the display screen being coupled to the processor, the memory storing computer program code including computer instructions, which, when read from the memory by the processor, cause the electronic device to perform the method as described 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 that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-14.

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

Images