An apparatus and method for dynamically mounting an application partition in an Android system at runtime

Abstract

The application discloses a kind of for Android terminal application partitioning runtime dynamic mounting device and method, belong to mobile storage management field.The device includes initial mounting unit, based on the event monitoring unit of vold, partition check unit, runtime migration control unit and abnormal back unit.System runs, the present application is captured by monitoring unit external storage signal, after verification compliance, by migration control unit IO suspension, application process freezing, mounting point from built-in partition to external partition remapping and environment thawing atomized switching.If device is pulled out, abnormal back unit immediately locks IO and restores default environment.The present application solves the pain point that native system application partition is fixed and hot plug is easy to crash, through kernel level IO mapping and process control cooperation, realizes that partition is under the premise of no restart inductive extension and safe back, significantly improves storage flexibility and running robustness.

Description

Technical Field

[0001] This invention relates to the field of mobile terminal storage management and operating system underlying file system technology, and in particular to a runtime dynamic mounting device and method for application partitions in an Android system. Background Technology

[0002] With the increasing richness of mobile smart terminal functions and the continuous expansion of application scale, users' demand for the number of installed applications (APPs) and data storage capacity has exploded. In the Android system architecture, the installation, running logic and data persistence of applications are highly dependent on the application partition designated by the system (usually the / app directory), and the storage specifications of this partition directly determine the application carrying capacity of the terminal. Currently, the mainstream application partition management solutions in the industry mainly include the following three categories: First, the native static mounting mechanism. During the Android system startup phase, it reads a fixed configuration file (such as fstab) and permanently mounts a specific physical partition (such as the mass partition) in the internal storage to the / app directory. The drawback of this mechanism is that the mounting relationship cannot be dynamically changed during system runtime. If the storage source needs to be adjusted, the underlying configuration must be modified and the terminal restarted, which cannot meet users' flexible expansion needs for storage space. Second, there is the Adoptable Storage solution. This solution allows external storage media to be formatted and merged with the built-in storage logic. However, this solution has serious security and stability vulnerabilities: once an external device is formatted, it is deeply bound to a specific terminal and does not support hot-swapping. If the external storage device is accidentally detached during system operation, it will cause the mounted node to fail instantly, leading to serious system-level crashes, application data loss, or file system metadata corruption. Third, portable mounting solutions based on common media transmission protocols. These solutions only recognize external devices as portable storage space for storing multimedia files or ordinary documents, and cannot map them as application partitions with execution permissions, thus preventing the direct installation and running of apps. In summary, existing technologies for application partition expansion generally face a trade-off between "flexibility" and "stability." Specifically, this manifests as: a lack of robust hot-swap anomaly protection mechanisms; the inability to seamlessly switch partition mount sources without restarting the system; and difficulties in convenient data management of external application partitions via a PC after mounting. Therefore, there is an urgent need for a device and method capable of securely and dynamically switching application partition mount sources during system runtime, with atomic back-switch protection capabilities.

[0003] Therefore, existing technologies still need to be improved. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the present invention provides a dynamic mounting device and method for Android system APP partitions, aiming to solve the technical problems in the prior art such as limited application partition storage space, lack of support for hot-swapping and seamless switching of external devices, and inconvenience in managing external application partition data.

[0005] The technical solution of the present invention is as follows: This invention provides a runtime dynamic mounting device for application partitions in an Android system, comprising: The initial mount unit is used to mount the first partition in the internal storage to the system application directory / app based on the fstab configuration during system startup, so as to establish the default application execution environment; The event listening unit is used to listen for the access and removal events of external storage devices in real time based on the event dispatch mechanism of the Android storage management service vold. The partition verification unit is used to obtain the file system attributes and security policy configuration of the target partition and perform compliance verification after detecting the access of an external storage device. A runtime migration control unit is used to perform the application execution environment mounting and migration operation while the system is continuously running, upon successful verification. The operation includes: Send an I / O suspend instruction to the kernel to pause write requests to the / app directory; Freeze the application processes associated with the / app directory; Unmount the first partition and remount the target partition to the / app directory; After mounting is complete, resume IO requests and unfreeze the application process. The abnormal rollback unit is used to perform a rollback operation when an external storage device is detected to be unplugged. This operation includes locking the current IO operation, cleaning up failed mount nodes, and remounting the first partition to the / app directory to restore the default application execution environment.

[0006] In one embodiment, the runtime migration control unit performs the mount migration operation through an atomic mount switching mechanism to ensure the continuity and consistency of the application execution environment during the switching process. The atomic mount switching mechanism maintains a mount state machine to ensure that no new process access requests are prohibited during the switching interval between unloading the first partition and mounting the target partition.

[0007] In one embodiment, the mount migration operation implements path remapping based on the mount namespace or bind mount mechanism.

[0008] In one embodiment, the verification content of the partition verification unit includes: Does the file system support Linux permission bits? Does it include a preset application partition identifier? Does the SELinux context conform to the system security policy?

[0009] In one embodiment, the runtime migration control unit forcibly triggers a file system synchronization operation before performing an I / O suspension, persisting the application data in the memory buffer to the storage medium, ensuring that the state of the partition to be mounted is at a data consistency checkpoint before performing mount point remapping.

[0010] In one embodiment, when the abnormal switchback unit detects the abnormal removal of an external storage device, it completes the switchback operation within a preset time threshold to avoid failure to access critical system executable files.

[0011] In one embodiment, the device is deployed in the vold storage management service of the Android system and implements control logic by extending its event dispatch mechanism.

[0012] In one embodiment, the partition verification unit outputs a prompt message through the system user interface when the verification fails.

[0013] In one embodiment, it also includes: The MTP mapping unit is used to map the target partition currently mounted to the / app directory to the access path of the Media Transport Protocol service.

[0014] In another aspect, the present invention provides a method for dynamically mounting application partitions based on the apparatus described in any one of the above claims, comprising: The system mounts the built-in partition to / app during startup; Detect the connection of external storage devices and perform partition verification; After verification, a runtime migration process including IO suspension, process freezing, mount switching and recovery operations is executed. When an external storage device is detected to be unplugged, a switchback process is executed to restore the default application execution environment.

[0015] In summary, this invention addresses the limitations of fixed mounting of application partitions in Android systems, which restricts expansion, and the instability of existing external storage solutions in hot-swappable scenarios. It provides a highly robust and flexible dynamic mounting device and method. By introducing kernel-level I / O suspension and process freezing mechanisms, this invention achieves runtime atomic switching of the / app directory mount source without disrupting system operation continuity. This solution not only ensures the compliance and security of external devices at the physical level through pre-existing attribute verification, but also eliminates the risk of system crashes caused by hot-plugging at the logical level through an automatic rollback mechanism, fundamentally resolving the inherent contradiction between storage flexibility and system stability. Furthermore, this invention utilizes MTP path mapping technology to establish a data interaction link between external application partitions and external computing devices, greatly improving the efficiency of application data management and user experience. The apparatus and method described in this invention represent not only a deep optimization of the native storage architecture of Android, but also a significant technological evolution in ensuring data security and system continuity in complex storage scenarios of mobile terminals.

[0016] Compared with the prior art, the present invention has at least the following beneficial effects: 1. Enabled "non-destructive" dynamic migration of critical system partitions. In the traditional Android architecture, mounting the / app partition has a very strong lifecycle dependency. Any attempt to unmount this partition at runtime usually causes the system to immediately trigger KernelPanic or enter an infinite loop due to the invalidation of the underlying file handle. This invention unexpectedly achieves physical source replacement of a system partition in a "busy state" without interrupting the operating system by precisely coordinating "IO suspension and application process state freezing." This seamless migration capability, like "changing valves while the heart is beating," far exceeds the expectations of existing technologies that require a restart or pre-static configuration. 2. A "software-hardware collaborative self-healing" mechanism was established for hot-swappable scenarios. In existing solutions, the unexpected detachment of external storage is considered a "catastrophic event," typically leading to a complete collapse of the storage stack and data block corruption. The unexpected effect of this invention is that it doesn't simply report an error or wait for user intervention; instead, through deep integration of the hot-swap event handling module and the anomaly protection service, it achieves environmental self-healing from a failed external device to the built-in mass partition within an extremely short millisecond threshold. This ability to transform a "fatal error" into a "millisecond-level smooth rollback" provides Android terminals with extremely high robustness for continuous operation in complex physical environments. 3. Overcomes the dynamic compatibility barriers of SELinux (Security, Security and Access Control) policies. High-version Android systems have extremely stringent verification standards for the SELinux context and permission bits of critical partitions. Dynamically mounted third-party partitions are often denied access due to mismatched labels. This invention unexpectedly introduces security policy substitution logic into the partition attribute verification unit, enabling external storage to obtain a security context identifier equivalent to the built-in native partition the moment it is connected. This allows external storage not only to store data but also to directly support the operation of system-level applications with high permission requirements, solving the long-standing industry problem of restricted external storage permissions. 4. It breaks through the "isolated" management limitations of system-level partitions. In conventional technologies, once a storage medium is mounted as a Linux system partition (such as an EXT4 formatted application partition), it is often "invisible" or "unreadable" to external computers (Windows / Mac). This invention, through an MTP access adapter module, creatively establishes a real-time mapping relationship between dynamically mounted application partitions and the MTP service. This design unexpectedly breaks down the barriers between the "system execution space" and the "user management space," allowing users to maintain core application data directly on their computers, just like managing a regular USB drive, without needing complex root privileges or ADB commands, greatly expanding the commercial practical value of the solution. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 A system structure block diagram of a runtime dynamic mounting device for application partitions in an Android system provided by the present invention; Figure 2 The present invention provides a flowchart of the method steps for dynamically mounting application partitions at runtime in an Android system. Detailed Implementation

[0018] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention is further described in detail below. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. The embodiments of the invention are described below in conjunction with the accompanying drawings.

[0019] One embodiment of the present invention provides a runtime dynamic mounting device for application partitions in an Android system. Please refer to [link to relevant documentation]. Figure 1 ,include: Initial mount unit 1 is used to mount the first partition in the internal storage to the system application directory / app based on the fstab configuration during system startup, so as to establish the default application execution environment; Event listening unit 2 is used to listen for access and removal events of external storage devices in real time based on the event dispatch mechanism of Android storage management service vold; Partition verification unit 3 is used to obtain the file system attributes and security policy configuration of the target partition and perform compliance verification after detecting the access of an external storage device. The runtime migration control unit 4 is used to perform the application execution environment mounting and migration operation while the system is continuously running, upon successful verification. The operation includes: Send an I / O suspend instruction to the kernel to pause write requests to the / app directory; Freeze the application processes associated with the / app directory; Unmount the first partition and remount the target partition to the / app directory; After mounting is complete, resume IO requests and unfreeze the application process. The abnormal rollback unit 5 is used to perform a rollback operation when the external storage device is detected to be unplugged, including locking the current IO operation, cleaning up the failed mount node, and remounting the first partition to the / app directory, so as to restore the default application execution environment.

[0020] Specifically, during the initial boot phase of the Android system, the initial mounting unit 1 first plays its foundational supporting role. Deeply integrated into the system startup process, this unit accurately identifies the first partition in the built-in UFS or eMMC storage medium by parsing the pre-configured Hardware Abstraction Layer (HAL) configuration file. After the system kernel completes its initial loading, this unit calls the mounting primitive to anchor the first partition (i.e., the mass partition) to the system's / app root node, thereby pre-building a stable execution environment for the Zygote process and subsequent system-level applications. This initial static mapping ensures that even in a vacuum state lacking external storage intervention, the terminal can still maintain the basic vitality of core communication and UI interaction.

[0021] As the system enters steady-state operation, Event Listening Unit 2 maintains a high-priority Netlink socket listener within the vold storage daemon, enabling sensitive capture of physical layer electrical signals. When an external high-speed storage medium is connected to the terminal's physical interface, the block device addition signal generated by the kernel is asynchronously captured by Event Listening Unit 2. This non-blocking listening mechanism effectively avoids the interference of hardware hot-plugging on the system's main thread, ensuring that the terminal's foreground application interaction remains absolutely smooth when the user is expanding storage.

[0022] After confirming the physical presence of the external device, partition verification unit 3 immediately initiates a multi-dimensional security scan of the target partition to build a robust chain of trust. This unit not only verifies the partition's integrity by comparing signature features in the file system superblock, but also delves deeper into the Linux kernel's security subsystem to perform compliance audits of the external partition's SELinux context. If the security labels in the target partition deviate from the system's default / app directory access policy, the verification unit will perform dynamic policy repair or permission reset, ensuring that even after the external storage is converted into a system partition, it remains under strict security sandbox mechanisms, blocking potential cross-partition attack paths at the source.

[0023] Once the security verification completes, the runtime migration control unit 4 begins executing the core "online replacement" process of this invention. This unit sends a FIFREEZE command to the virtual file system layer, instantly locking the IO request queue pointing to the / app directory in kernel mode and forcibly synchronizing all dirty memory data to the storage medium. Immediately afterward, the unit uses the cgroup freezer subsystem to implement "logical hibernation" for all application processes with handle dependencies on this path, putting the process state machine in a controllable suspended state. In a vacuum moment ensuring no active IO conflicts, the migration control unit performs atomic mount point remapping, smoothly redirecting the logical pointer of / app from the built-in first partition to the target partition on external storage. After the switch is complete, with the IO blocking released and the process state unfrozen, the application instruction flow continues smoothly in the new physical space; the entire process is almost transparent to the upper-layer user.

[0024] To address the risk of unexpected disconnection of external storage media, the anomaly recovery unit 5 employs a highly responsive, self-healing protection system. Once the event monitoring unit 2 reports an extreme signal of physical link failure, the recovery unit, leveraging its preemptive scheduling authority, intercepts all abnormal calls pointing to the failed address within a millisecond-level time window. By invoking the kernel's delayed unloading mechanism, this unit quickly cleans up damaged mount tree nodes and immediately re-anchors the / app directory to the always-online built-in first partition. Because a complete running copy is established in the initial stage, this instantaneous path recovery mechanism effectively resists kernel crashes caused by hardware failures, ensuring the resilience of the system's operating environment and business continuity.

[0025] Ultimately, to further unlock the commercial value of the dynamic mounting solution, the MTP mapping unit bridges the data interaction gap between the system application layer and the underlying storage. This unit dynamically reconstructs the node tree of the media transmission protocol, mapping the target partition currently actively mounted to the / app directory in real time to a virtual file system path perceptible to the computer. This design breaks the long-standing "isolated" management deadlock of Android system partitions, allowing users to intuitively manage and quickly migrate application data on external computing devices via a standard USB link without obtaining underlying root privileges, greatly enhancing the usability of the terminal.

[0026] In a further embodiment, the runtime migration control unit 4 performs the mount migration operation through an atomic mount switching mechanism to ensure the continuity and consistency of the application execution environment during the switching process. The atomic mount switching mechanism maintains a mount state machine to ensure that no new process access requests are prohibited during the switching interval between unloading the first partition and mounting the target partition.

[0027] During runtime migration of the application environment, this device employs an atomic mount switching mechanism to ensure the continuity and consistency of the system state. Atomicity refers to encapsulating the series of actions of unloading the built-in first partition and mounting the external target partition into an indivisible logical whole. The runtime migration control unit 4 maintains a dynamic mount state machine in kernel mode. When the switching process begins, this state machine enters a critical section locking mode. In this mode, the system temporarily blocks all file search and open requests pointing to the / app path through a mutex semaphore mechanism at the Virtual File System (VFS) layer.

[0028] The brilliance of this approach lies in its avoidance of file handle deadlocks or application crashes caused by accessing invalid paths during the millisecond-level "logical window" when the old mount point has been removed and the new mount point is not yet fully ready. Through this atomic control, the system appears at the observation level as an instantaneous replacement of the mount source, thus ensuring the absolute continuity of the application execution environment during the switching process and achieving truly seamless migration.

[0029] In a further embodiment, the mount migration operation implements path remapping based on the mount namespace or bind mount mechanism.

[0030] To achieve higher-level path compatibility and execution efficiency, the aforementioned mount migration operation implements deep path remapping based on the mount namespace mechanism at the underlying level. Specifically, the runtime migration control unit 4 utilizes the Linux kernel's clone flag to create independent mount view isolation for the affected application process set. This technology allows the system to retain the original mount topology in the global namespace, while precisely switching the physical endorsement of the / app directory from the built-in first partition to the external storage partition within a specific application namespace. This implementation can implement differentiated mount strategies for different application sets, and due to its isolation characteristics, it effectively prevents dynamic mount operations from causing logical interference to other critical mount points in the system kernel, greatly improving storage access security in a multi-task concurrent environment.

[0031] As an alternative implementation path, the aforementioned mount migration operation can also be implemented based on the bind mount mechanism. In this embodiment, the runtime migration control unit 4 utilizes the kernel's file system directory tree redirection feature. This unit first establishes a mirror directory aligned with the system standard in the target partition of the external storage device, and then dynamically binds this mirror directory to the global / app mount point by calling the mount system call with the MS_BIND flag set. In this mode, the kernel VFS layer does not need to re-parse the entire file system's superblock stack; instead, it achieves a smooth replacement of physical space by modifying the pointers of directory entries (dentries). This bind mount-based remapping scheme significantly reduces the system call time during the switching process and ensures that application executables in the external storage can be scheduled by the system with the native partition's permission level.

[0032] In a further embodiment, the verification content of the partition verification unit 3 includes: Does the file system support Linux permission bits? Does it include a preset application partition identifier? Does the SELinux context conform to the system security policy?

[0033] To ensure the security boundaries and system compatibility of the dynamic mounting process, the partition verification unit 3 executes a closed-loop compliance verification process after detecting an external storage device.

[0034] First, at the physical file system level, this unit performs a format scan on the target device to verify whether it supports Linux POSIX Permissions. This step is crucial because Android applications rely on strict UID (User Identifier) ​​and GID (Group Identifier) ​​management; if the external storage uses the traditional FAT32 format that does not support permission bits, the verification unit will reject the mount request to prevent permission gaps in the application execution environment.

[0035] Secondly, the verification unit checks whether the target device contains a preset application partition identifier by retrieving the encrypted signature or preset partition label from a specific sector of the target device. This mechanism effectively filters out unauthenticated ordinary storage media, ensuring that only expansion cards that have been initialized or authorized by the system can be mapped to the core / app directory.

[0036] Finally, the verification unit performs a deep match of the SELinux security policy. Because the Android system has stringent security context requirements for executable files in the ` / app` directory, the verification unit performs recursive `restorecon` checks on file nodes of external partitions by calling the `libselinux` library interface. If a missing security label or a conflict with the current kernel policy is detected, the unit will attempt to repair the security context before mounting to ensure that applications on external storage can pass the system's mandatory access control (MAC) audit, avoiding frequent application crashes or system permission errors caused by label mismatches.

[0037] In a further embodiment, the runtime migration control unit 4 forcibly triggers a file system synchronization operation before performing an IO suspension, persisting the application data in the memory buffer to the storage medium, ensuring that the state of the partition to be mounted is at a data consistency checkpoint before performing mount point remapping.

[0038] While the migration control unit 4 executes the IO suspend instruction during runtime, the system introduces a sophisticated cache synchronization mechanism to ensure that data is not lost or logically corrupted during the moment of switching mount sources.

[0039] When the migration command is issued, the kernel does not immediately disconnect the I / O link, but instead triggers a global fsync operation. This operation forces a traversal of the kernel page cache, immediately persisting all application data marked as "dirty pages," metadata changes, and pending file system logs to the first partition of the current internal storage.

[0040] During this process, the runtime migration control unit 4 interacts with the super_block structure of the file system driver layer to lock the write queue of the current partition. Through this atomic timing of "synchronization first, suspension later," the system ensures that all write requests initiated by the application layer before the switch command is issued have been safely written. This design not only prevents incomplete physical block writes (torn writes) caused by sudden mount point failure, but also ensures that the file system state machine can be restarted from a consistent checkpoint after switching to external storage, thereby fundamentally guaranteeing the dual integrity of application-level data and system-level metadata during dynamic switching.

[0041] In a further embodiment, when the abnormal switchback unit 5 detects the abnormal removal of the external storage device, it completes the switchback operation within a preset time threshold to avoid failure to access critical system executable files.

[0042] To ensure system survivability in extreme hardware failure scenarios, the abnormal switchback unit 5 incorporates a fast response mechanism based on a preset time threshold. When an external storage device generates an abnormal removal signal due to physical collision, poor electrical contact, or forced removal, the system kernel immediately enters an I / O wait state. If not handled properly, it will trigger the Android system framework layer's "watchdog" to restart.

[0043] In this embodiment, the abnormal rollback unit 5 starts a high-precision timer the instant it detects a removal event. Within a preset millisecond-level time threshold (e.g., 100ms to 500ms, depending on the system kernel scheduling cycle), the unit forcibly interrupts all pending I / O sequences pointing to the original external storage address and quickly executes the remapping operation of the first partition. This time-constrained rollback strategy aims to achieve "in-situ self-healing" of the storage environment before access requests for critical system executable files (such as Shared Libraries or Dex files) completely time out and trigger application crashes. By closing the loop to clean up failed nodes and restore the default environment within a very short time window, this device effectively avoids system soft restarts or hard crashes caused by sudden removal of storage media, significantly improving the operational reliability of the device in complex physical environments.

[0044] In a further embodiment, the device is deployed in the vold storage management service of the Android system and implements control logic by extending its event distribution mechanism.

[0045] This device is physically deployed deep within the Android system's underlying storage management daemon, vold (vold), rather than running as a regular user-space application. This system-level architectural integration ensures that the device has advanced privileges to directly manipulate the kernel mount table and modify kernel security policies.

[0046] Specifically, this device achieves the sinking of control logic by extending vold's Event Dispatching Framework. Event Listening Unit 2 utilizes vold's existing NetlinkManager module to obtain underlying UEvent messages and adds a new layer of business processing state machine for dynamically mounted / app directories. This means that when external storage is inserted, the extended logic within the vold process can directly complete file system attribute detection and security context injection in kernel mode, triggering the runtime migration control unit 4 without complex inter-process communication (IPC).

[0047] Furthermore, because it is deployed within the vold service, this device can directly call the native interface of VolumeManager to perform partition formatting checks and mount path locking. This architecture not only greatly reduces instruction latency during dynamic mounting, but more importantly, it leverages the security barriers of Android's native storage service to ensure that dynamic mounting operations have the same permission level and stability as system initialization mounting, fundamentally different from virtualization mounting schemes implemented through ordinary APP layers.

[0048] In a further embodiment, the partition verification unit 3 outputs a prompt message through the system user interface when the verification fails.

[0049] To ensure transparency in the dynamic mounting process and guide users to operate correctly, partition verification unit 3 has established an exception feedback mechanism based on the system user interface when executing the pre-review logic. When an external storage device is connected via a physical interface, if partition verification unit 3 finds that any indicator does not meet the preset standard during the process of retrieving the UUID identifier, verifying the file system POSIX permissions, or comparing the SELinux security context, the verification unit will immediately terminate the subsequent runtime migration process.

[0050] During this process, the verification unit sends an asynchronous signal containing an error code to the system framework layer. Upon receiving this signal, the system UI component outputs targeted prompts in real-time in the top-level floating window or notification bar of the terminal display interface. These prompts not only include the conclusion of verification failure but also further refine the information with specific repair suggestions, such as indicating that the storage card has not been formatted and certified, the file system is corrupted, or the SELinux policy is incompatible. This feedback mechanism effectively avoids blind spots in user perception caused by background mounting failures. While ensuring the absolute security of the underlying system mounting environment, it significantly improves the guidance of human-computer interaction and ensures that the built-in storage partition can stably maintain its current mounting state even under abnormal conditions.

[0051] In a further embodiment, it also includes: The MTP mapping unit is used to map the target partition currently mounted to the / app directory to the access path of the Media Transport Protocol service.

[0052] This device further integrates an MTP (Media Transfer Protocol) mapping unit, aiming to break the "data silo" state of application partitions after dynamic mounting. After the runtime migration control unit 4 completes the remapping operation of the / app directory to the external storage target partition, the MTP mapping unit synchronously starts the protocol stack-level path refresh logic.

[0053] This unit communicates with the underlying MediaProvider and MtpServer processes to dynamically map the physical path of the target partition currently actively mounted to the / app directory to a virtual access node in the MTP protocol tree. Specifically, the MTP mapping unit creates a symbolic link pointing to the external storage partition at the virtual file system level or uses bind mount technology to map it to a path scannable by the media database.

[0054] Through this mapping relationship, when the terminal is connected to an external computing device (such as a PC) via a USB interface, the user can intuitively see the dynamic application partition outside of "internal storage" through a standard file manager view. This design allows users to directly back up, migrate, and organize application data across devices without relying on complex root privileges or developer debugging commands, greatly expanding the commercial applicability of dynamic mounting solutions in data sharing scenarios.

[0055] Another aspect of this invention provides a method for dynamically mounting application partitions based on the aforementioned device. Please refer to [link to relevant documentation]. Figure 2 ,include: S1. Mount the built-in partition to / app when the system starts up; S2. Detect the connection of the external storage device and perform partition verification; S3. After the verification is passed, execute the runtime migration process, which includes IO suspension, process freezing, mount switching and recovery operations. S4. When an external storage device is detected to be unplugged, a switchback process is executed to restore the default application execution environment.

[0056] First, the default mount is executed during the system initialization phase. During the Android terminal's power-on boot process, the system reads the fstab static mapping table of the internal storage and mounts the first partition (the internal mass partition) to the / app directory. This step establishes the basic application runtime environment for the system, enabling core system services to complete initial loading without the intervention of external storage.

[0057] Secondly, the system detects and verifies the external storage devices and their partitions. The system uses the underlying vold service to poll or monitor hardware interface status changes in real time. Once an external storage device is detected, the system does not immediately perform a mount switch; instead, it first extracts the metadata of the device's partitions. By comparing the pre-defined UUID unique identifier, verifying whether the file system supports POSIX permissions, and scanning for SELinux security context labels, the system constructs a complete partition access review logic. If the verification results do not meet the pre-defined criteria, the system will terminate the migration process and maintain the current mount state of the internal partitions.

[0058] Subsequently, the runtime migration control process is executed. Upon successful verification, the system initiates an atomic environment migration sequence. This process is detailed as follows: First, a FIFREEZE instruction is issued to suspend the kernel-level IO write request to the / app directory and synchronize dirty data to the physical medium. Next, a process freezer (Freezer) is used to logically suspend all application processes that depend on this path, clearing all active file handle conflicts. During the vacuum period of IO and process dual locking, the system performs a redirection of the mount source, switching the physical endorsement of the / app directory from the internal first partition to the external storage target partition. After the switch is complete, the system immediately releases the IO block and sends a defrost signal, allowing the application process to seamlessly continue executing its instruction stream in the new storage space.

[0059] Finally, an automatic rollback process is implemented in case of abnormal removal. During system operation, if an external storage device is detected to have detached abnormally (hot-plug event), the system will immediately trigger preemptive rollback logic. This process includes: instantly intercepting I / O calls pointing to invalid addresses, cleaning up damaged virtual nodes through the kernel's delayed unloading mechanism, and re-anchoring the / app directory back to the always-online built-in first partition. Through this self-healing process, the system restores the default application execution environment within a very short time window, avoiding kernel crashes caused by the loss of critical code segments.

[0060] In summary, this invention provides a complete solution for runtime dynamic mounting of application partitions in the Android system, constructing a collaborative defense system from underlying physical perception to high-level logical control.

[0061] This invention overcomes the technical bottleneck of traditional storage management solutions in balancing flexibility and stability by introducing sophisticated process freezing, I / O flow control, and atomic remapping mechanisms into the Android system architecture. Compared to existing technologies, this invention not only achieves seamless expansion of the application environment without restarting the system, but also ensures the continuous operation capability of the terminal in complex physical plug-and-play environments through preset time threshold protection and abnormal switchback logic.

[0062] Furthermore, the deep integration of this invention with the underlying system storage service vold, and the innovative mapping of the MTP data link, enable the solution to significantly improve user efficiency in managing application data while ensuring system-level permission security. This technological evolution, which balances system robustness, storage flexibility, and ease of interaction, not only provides a solid foundation for high-capacity mobile application environments but also offers a highly valuable implementation paradigm for the future evolution of mobile terminals towards multi-media, highly integrated storage architectures.

[0063] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A runtime dynamic mounting device for application partitions in an Android system, characterized in that, include: The initial mount unit is used to mount the first partition in the internal storage to the system application directory / app based on the fstab configuration during system startup, so as to establish the default application execution environment; The event listening unit is used to listen for the access and removal events of external storage devices in real time based on the event dispatch mechanism of the Android storage management service vold. The partition verification unit is used to obtain the file system attributes and security policy configuration of the target partition and perform compliance verification after detecting the access of an external storage device. A runtime migration control unit is used to perform the application execution environment mounting and migration operation while the system is continuously running, upon successful verification. The operation includes: Send an I / O suspend instruction to the kernel to pause write requests to the / app directory; Freeze the application processes associated with the / app directory; Unmount the first partition and remount the target partition to the / app directory; After mounting is complete, resume IO requests and unfreeze the application process. The abnormal rollback unit is used to perform a rollback operation when an external storage device is detected to be unplugged. This operation includes locking the current IO operation, cleaning up failed mount nodes, and remounting the first partition to the / app directory to restore the default application execution environment.

2. The apparatus according to claim 1, characterized in that, The runtime migration control unit executes the mount migration operation through an atomic mount switching mechanism to ensure the continuity and consistency of the application execution environment during the switching process. The atomic mount switching mechanism maintains a mount state machine to ensure that no new process access requests are prohibited during the switching interval between unloading the first partition and mounting the target partition.

3. The apparatus according to claim 1, characterized in that, The mount migration operation implements path remapping based on the mount namespace or bind mount mechanism.

4. The apparatus according to claim 1, characterized in that, The verification content of the partition verification unit includes: Does the file system support Linux permission bits? Does it include a preset application partition identifier? Does the SELinux context conform to the system security policy? 5. The apparatus according to claim 1, characterized in that, Before executing IO suspension, the runtime migration control unit forcibly triggers a file system synchronization operation to persist the application data in the memory buffer to the storage medium, ensuring that the state of the partition to be mounted is at a data consistency checkpoint before the mount point remapping is performed.

6. The apparatus according to claim 1, characterized in that, When the abnormal switchback unit detects the abnormal removal of an external storage device, it completes the switchback operation within a preset time threshold to avoid failure to access critical system executable files.

7. The apparatus according to claim 1, characterized in that, The device is deployed in the vold storage management service of the Android system and implements control logic by extending its event distribution mechanism.

8. The apparatus according to claim 1, characterized in that, When the partition verification unit fails, it outputs a prompt message through the system user interface.

9. The apparatus according to claim 1, characterized in that, Also includes: The MTP mapping unit is used to map the target partition currently mounted to the / app directory to the access path of the Media Transport Protocol service.

10. A method for dynamically mounting application partitions based on the apparatus described in any one of claims 1-9, characterized in that, include: The system mounts the built-in partition to / app during startup; Detect the connection of external storage devices and perform partition verification; After verification, a runtime migration process including IO suspension, process freezing, mount switching and recovery operations is executed. When an external storage device is detected to be unplugged, a switchback process is executed to restore the default application execution environment.

Images