File synchronization systems and methods

Abstract

This application belongs to the field of automotive technology and discloses a file synchronization system and method. This application generates a hardware interrupt signal when a change in electrical signal is detected during the insertion of a USB device at the hardware layer. Then, the kernel layer identifies the device type of the USB device and creates a block device node based on the device type. Next, the native layer performs a file system mount operation based on the detected file system type. Finally, the framework layer broadcasts information carrying the device path corresponding to the mount operation to the application layer. The application layer then displays the file list corresponding to the USB device based on the device path information. This application, through a complete event transmission chain from the hardware layer, kernel layer, native layer, framework layer, and application layer, ensures that the file list in the USB device remains consistent with the actual state even with frequent USB device insertion and removal.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and more particularly to a file synchronization system and method. Background Technology

[0002] In-vehicle multimedia systems typically need to manage media files on various storage devices, including built-in storage and multiple Universal Serial Bus (USB) storage devices, involving collaboration across multiple system layers from the underlying hardware to the upper-level applications. However, frequent plugging and unplugging of USB devices can easily lead to file list desynchronization, resulting in ghost files or lost files. Therefore, ensuring consistency between the file list and the actual state under frequent USB device plugging and unplugging has become a pressing issue. Summary of the Invention

[0003] The main purpose of this application is to provide a file synchronization system and method, which aims to solve the technical problem of ensuring that the file list is consistent with the actual state when USB devices are frequently plugged and unplugged.

[0004] To achieve the above objectives, this application provides a file synchronization system, the file synchronization system comprising:

[0005] The hardware layer is used to generate a hardware interrupt signal when a change in electrical signal is detected when a USB device is plugged in. The kernel layer is used to identify the device type corresponding to the USB device when a hardware interrupt signal is detected by the hardware layer, and to create a block device node based on the device type. The Native layer is used to perform file system mount operations based on the detected file system type when a new block device is detected based on the block device node. The Framework layer is used to send a broadcast carrying the device path information corresponding to the mount operation to the application layer when it receives the mount operation update from the Native layer. The application layer is used to display a list of files corresponding to the USB device based on the device path information when it receives a broadcast carrying device path information sent by the Framework layer.

[0006] Optionally, the file synchronization system further includes: The HAL layer is used to provide a unified interface for the Native layer.

[0007] Optionally, the application layer is further configured to, upon receiving a broadcast carrying device path information sent by the Framework layer, merge events within a preset time period based on the device path information using a debouncing processor; The application layer is also used to determine whether the merged event is a mount event, and to display the file list corresponding to the USB device based on the determination result.

[0008] Optionally, the application layer is further configured to encapsulate the device path information into a UsbEvent object when it receives a broadcast carrying device path information sent by the Framework layer; The application layer is also used to use the debouncing processor to search for whether there is an event to be processed based on the device path information in the UsbEvent object, and obtain the search result; The application layer is also used to merge events within a preset time period based on the search results.

[0009] Optionally, the application layer is further configured to determine the final state of the merged events; The application layer is also used to determine the event type based on the final state of the event; The application layer is also used to determine whether the merged event is a mount event based on the event type, and to display the file list corresponding to the USB device based on the determination result.

[0010] Optionally, the application layer is further configured to determine whether the merged event is a mounting event based on the event type; The application layer is also used to add the file list corresponding to the USB device based on the merged event when the merged event is a mount event, and to display the added file list. The application layer is further configured to, when the merged event is an uninstallation event, remove the file list corresponding to the USB device based on the merged event, and display the removed file list.

[0011] Optionally, the application layer is further configured to determine the new filename corresponding to the merged event, and to determine the target filename of the file list corresponding to the USB device; The application layer is also used to match the newly added file name with the target file name to obtain a matching result; The application layer is also used to determine whether to add the file list corresponding to the USB device based on the matching result.

[0012] Optionally, the application layer is further configured to, when the matching result is that the newly added file name is consistent with the target file name, select the target file whose file name matches from the file list, and determine the newly added path corresponding to the merged event and the target path corresponding to the target file; The application layer is further configured to, if the newly added path and the target path are the same, add the file list corresponding to the USB device if the newly added file corresponding to the merged event exists.

[0013] Optionally, the application layer is further configured to determine all files in the added file list, and to determine the device identifier, full file path, and file modification time corresponding to each file; The application layer is also used to extract the storage device identifier from the complete file path; The application layer is also used to concatenate the storage device identifier, the complete file path, and the file modification time, and calculate the hash value corresponding to the concatenated field. The application layer is also used to generate a signature based on the hash value, update the added file list based on the signature, and display the updated file list.

[0014] Furthermore, to achieve the above objectives, this application also provides a file synchronization method, which is applied to the file synchronization system described above, and the file synchronization method includes: The hardware layer generates a hardware interrupt signal when it detects a change in electrical signal when a USB device is inserted. When the kernel layer detects a hardware interrupt signal generated by the hardware layer, it identifies the device type corresponding to the USB device and creates a block device node based on the device type. When the native layer detects a new block device based on the block device node, it performs a file system mount operation according to the detected file system type. When the Framework layer receives the mount operation update from the Native layer, it sends a broadcast carrying the device path information corresponding to the mount operation to the application layer. When the application layer receives a broadcast containing device path information sent by the Framework layer, it displays a list of files corresponding to the USB device based on the device path information.

[0015] This application generates a hardware interrupt signal when a change in electrical signal is detected during USB device insertion at the hardware layer. Then, at the kernel layer, upon detecting the hardware interrupt signal, it identifies the device type of the USB device and creates a block device node based on that type. Next, at the native layer, upon detecting a new block device based on the block device node, it performs a file system mount operation according to the detected file system type. Then, at the framework layer, upon receiving the mount operation update from the native layer, it broadcasts a message carrying the device path information corresponding to the mount operation to the application layer. Finally, at the application layer, upon receiving the broadcast message carrying the device path information from the framework layer, it displays the file list corresponding to the USB device based on the device path information. This application, through a complete event transmission chain from the hardware layer, kernel layer, native layer, framework layer, and application layer, covering multiple layers of the Android system, achieves file synchronization within the USB device, thus ensuring consistency between the file list and the actual state of the USB device even with frequent plugging and unplugging. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the structure of the first embodiment of the document synchronization system of this application; Figure 2 This is a USB storage architecture diagram of an embodiment of the document synchronization system of this application; Figure 3 This is a flowchart illustrating a triple-matching security strategy of an embodiment of the document synchronization system of this application. Figure 4 This is a schematic diagram illustrating the process of composite signature cache isolation in an embodiment of the document synchronization system of this application; Figure 5 This is a flowchart illustrating the first embodiment of the document synchronization method of this application.

[0019] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is as follows: a hardware layer, used to generate a hardware interrupt signal when a change in electrical signal is detected when a USB device is inserted; a kernel layer, used to identify the device type corresponding to the USB device when the hardware interrupt signal generated by the hardware layer is detected, and to create a block device node based on the device type; a native layer, used to perform a file system mount operation according to the detected file system type when a new block device is detected based on the block device node; a framework layer, used to send a broadcast carrying device path information corresponding to the mount operation to the application layer when the mount operation update is received from the native layer; and an application layer, used to display a file list corresponding to the USB device based on the device path information when the broadcast carrying device path information is received from the framework layer.

[0023] In-vehicle multimedia systems typically need to manage media files on various storage devices, including built-in storage and multiple Universal Serial Bus (USB) storage devices, involving collaboration across multiple system layers from the underlying hardware to the upper-level applications. However, frequent plugging and unplugging of USB devices can easily lead to file list desynchronization, resulting in ghost files or lost files.

[0024] This application generates a hardware interrupt signal when a change in electrical signal is detected during USB device insertion at the hardware layer. Then, at the kernel layer, upon detecting the hardware interrupt signal, it identifies the device type of the USB device and creates a block device node based on that type. Next, at the native layer, upon detecting a new block device based on the block device node, it performs a file system mount operation according to the detected file system type. Then, at the framework layer, upon receiving the mount operation update from the native layer, it broadcasts a message carrying the device path information corresponding to the mount operation to the application layer. Finally, at the application layer, upon receiving the broadcast message carrying the device path information from the framework layer, it displays the file list corresponding to the USB device based on the device path information. This application, through a complete event transmission chain from the hardware layer, kernel layer, native layer, framework layer, and application layer, covering multiple layers of the Android system, achieves file synchronization within the USB device, thus ensuring consistency between the file list and the actual state of the USB device even with frequent plugging and unplugging.

[0025] This application provides a file synchronization system, referring to... Figure 1 , Figure 1 This is a schematic diagram of the structure of the first embodiment of the document synchronization system of this application.

[0026] In this embodiment, the hardware layer is used to generate a hardware interrupt signal when a change in electrical signal is detected when a USB device is inserted.

[0027] It is understood that the file synchronization system in this embodiment can be an Android system USB storage processing architecture, involving multiple layers of the Android system, including the hardware layer, kernel layer, native layer, framework layer, application layer, etc.

[0028] It should be understood that the hardware layer can be a USB controller, which is responsible for physical layer communication, and USB devices connect through a USB interface. When a USB device is plugged into the vehicle system's USB interface, the USB controller detects a change in electrical signals, at which point it can generate a hardware interrupt signal.

[0029] The kernel layer is used to identify the device type corresponding to the USB device when a hardware interrupt signal is detected by the hardware layer, and to create a block device node based on the device type.

[0030] Understandably, the kernel layer can be the USB driver subsystem of the operating system kernel (Linux kernel), which can identify the device type corresponding to the USB device when it receives a hardware interrupt signal, such as a mass storage device (MassStorage Class).

[0031] It should be understood that block device drivers can create block device nodes corresponding to the device type, such as / dev / block / sda1. File system drivers, such as FAT32 / exFAT / NTFS, are responsible for resolving the file system structure.

[0032] Furthermore, in this embodiment, the file synchronization system further includes a HAL layer, which provides a unified interface for the Native layer.

[0033] In a specific implementation, the file synchronization system may also include a Hardware Abstraction Layer (HAL). The HAL layer is positioned between the kernel layer and the native layer. It provides hardware abstraction through the USB HAL and Storage HAL, shielding the differences in the underlying hardware. They are used to abstract and standardize the access interfaces of USB hardware and storage devices, respectively. In this embodiment, it can provide a unified hardware access interface for the upper layer, i.e., the native layer.

[0034] The Native layer is used to perform file system mount operations based on the detected file system type when a new block device is detected based on the block device node.

[0035] Understandably, the Native layer refers to the low-level code layer written in C / C++ that runs directly on top of the device's operating system (usually Linux). In this embodiment, the vold (Volume Daemon) daemon in the Native layer can listen for kernel events via netlink. If a new block device is detected by listening for kernel events, the file system type can be probed.

[0036] It should be understood that file system mounting operations can be performed based on the file system type. Specifically, `vold` executes the `mount` command to mount the file system to a specified path, such as ` / storage / usbX`. The repository (libstorage) provides storage-related native interfaces.

[0037] The Framework layer is used to send a broadcast carrying the device path information corresponding to the mount operation to the application layer when it receives the mount operation update from the Native layer.

[0038] Understandably, the Framework layer refers to the application framework layer. When it receives a mount operation update from the Native layer, that is, when the StorageManagerService receives a status update from vold, it sends an ACTION_MEDIA_MOUNTED broadcast to the application layer. This broadcast carries the device path information corresponding to the mount operation.

[0039] The application layer is used to display a list of files corresponding to the USB device based on the device path information when it receives a broadcast carrying device path information sent by the Framework layer.

[0040] It should be understood that after receiving a broadcast, the USB broadcast receiver (UsbBroadcastReceiver) in the application layer can access the media data through the content resolver to extract the device path information, and then display the file list corresponding to the USB device based on the device path information.

[0041] In the specific implementation, refer to Figure 2 , Figure 2 This is a USB storage architecture diagram of an embodiment of the document synchronization system of this application. Figure 2As shown, the USB storage architecture diagram includes the following layers: Hardware Layer: The USB controller is responsible for physical layer communication, and USB storage devices connect via USB interfaces. When a device is inserted, the USB controller detects a change in electrical signals and generates a hardware interrupt. Kernel Layer: The Linux kernel's USB driver subsystem handles hardware interrupts and identifies device types (such as Mass Storage Class). The block device driver creates the corresponding device node (such as / dev / block / sda1), and the file system driver (FAT32 / exFAT / NTFS) is responsible for parsing the file system structure. HAL Layer: The USB HAL and Storage HAL provide hardware abstraction, shielding the underlying hardware differences and providing a unified interface for the upper layers. Native Layer: The vold (Volume Daemon) daemon listens for kernel events, performs mount / unmount operations, and mounts the file system to a specified path (such as / storage / usb0). libstorage provides storage-related native interfaces. Framework Layer: StorageManagerService manages storage device status, maintains volume (VolumeInfo) and physical disk (DiskInfo) information, MediaProvider manages the media database, MediaScanner scans for newly added media files, and ContentResolver provides the content access interface. Application Layer: Applications receive storage status change broadcasts via USB Broadcast Receiver (UsbReceiver) and access media data via ContentResolver.

[0042] This embodiment generates a hardware interrupt signal when a change in electrical signal is detected during USB device insertion at the hardware layer. Then, upon detecting the hardware interrupt signal, the kernel layer identifies the device type of the USB device and creates a block device node based on that type. Next, the native layer, upon detecting a new block device based on the block device node, performs a file system mount operation according to the detected file system type. Finally, upon receiving the mount operation update from the native layer, the framework layer broadcasts a message carrying the device path information to the application layer. Finally, upon receiving the broadcast message from the framework layer, the application layer displays the file list corresponding to the USB device based on the device path information. This embodiment, through a complete event transmission chain from the hardware layer, kernel layer, native layer, framework layer, and application layer, covers multiple layers of the Android system. This transmission chain enables file synchronization within the USB device, ensuring consistency between the file list and the actual state of the USB device even with frequent plugging and unplugging.

[0043] Based on the first embodiment described above, a second embodiment of the document synchronization system of this application is proposed.

[0044] In this embodiment, the application layer is further configured to, upon receiving a broadcast carrying device path information sent by the Framework layer, merge events within a preset time period based on the device path information using a debouncing processor.

[0045] Understandably, when the application layer receives a broadcast carrying device path information sent by the Framework layer, it can use a debouncing processor to merge events within a preset time period based on the device path information. Specifically, the debouncing processor can merge multiple USB plug-in / plug-out events within a short period of time to obtain the merged events.

[0046] Furthermore, to achieve intelligent de-jittering, in this embodiment, the application layer is further configured to encapsulate the device path information into a UsbEvent object upon receiving a broadcast carrying device path information sent by the Framework layer; the application layer is further configured to use the de-jittering processor to search for the existence of an event to be processed based on the device path information in the UsbEvent object, and obtain the search result; the application layer is further configured to merge events within a preset time period based on the search result.

[0047] It should be understood that when the application layer receives a broadcast containing device path information from the Framework layer, it encapsulates the device path information into a USB event (UsbEvent) object. The event bus adopts the observer pattern to manage the registration and deregistration of multiple listeners, and enters the debouncing process upon receiving an event.

[0048] Understandably, the application layer is also used to search for pending events using the device path information as the key through the debouncing processor, and obtain search results, which may include whether there are pending events or not.

[0049] In the specific implementation, if an event to be processed is found, it is canceled and the timer is restarted. If no new event is found after waiting for a preset time, events within a preset time period can be merged. The preset time period can be 500 milliseconds, 600 milliseconds, etc. All events from before the preset time period to the current time can be merged to obtain the merged event, thereby merging multiple plug-in events in a short period of time and avoiding repeated processing in a short period of time.

[0050] The application layer is also used to determine whether the merged event is a mount event, and to display the file list corresponding to the USB device based on the determination result.

[0051] Furthermore, in this embodiment, the application layer is also used to determine the final state of the merged event; the application layer is also used to determine the event type based on the final state of the event; the application layer is also used to determine whether the merged event is a mount event based on the event type, and to display the file list corresponding to the USB device based on the determination result.

[0052] Understandably, the final state of the merged event can also be determined, and the debouncing processor distributes the final state of the event to the UsbStorageManager. The UsbStorageManager determines the event type corresponding to the final state of the event, and then determines whether the merged event is a mount event based on the event type. Based on the determination result, it performs corresponding processing to display the file list corresponding to the USB device.

[0053] Furthermore, in this embodiment, the application layer is also used to determine whether the merged event is a mount event based on the event type; the application layer is also used to add the file list corresponding to the USB device based on the merged event when the merged event is a mount event, and display the added file list; the application layer is also used to remove the file list corresponding to the USB device based on the merged event when the merged event is an unmount event, and display the removed file list.

[0054] It should be understood that if the merged event is a mount event, a StorageDevice object can be created, device files can be scanned asynchronously, and the list can be updated. This allows the file list corresponding to the USB device to be added based on the merged event, and the files corresponding to the merged event can be added to the file list corresponding to the USB device and displayed.

[0055] Understandably, if the merged event is an unload event, the cache can be cleared and file records removed, thereby removing the file list corresponding to the USB device based on the merged event. The files corresponding to the merged event can be removed from the file list corresponding to the USB device, and the list of removed files can be displayed.

[0056] This embodiment, through the application layer, upon receiving a broadcast carrying device path information from the Framework layer, uses a debouncing processor to merge events within a preset time period based on the device path information. It then determines whether the merged events are mount events and displays the file list corresponding to the USB device based on the determination result. This embodiment, by using a debouncing processor to merge events within a preset time period based on device path information, can merge multiple USB plug-in / unplug events within a short period. Then, it performs corresponding processing based on the event type of the merged events, thereby displaying the final file list corresponding to the USB device.

[0057] Based on the above embodiments, a third embodiment of the document synchronization system of this application is proposed.

[0058] In this embodiment, the application layer is further configured to determine the new filename corresponding to the merged event and the target filename of the file list corresponding to the USB device.

[0059] Understandably, when performing operations such as file deletion and moving, a triple matching method can be used to ensure the accuracy of the operation. First, the new file name corresponding to the merged event can be determined, and then the target file name in the file list corresponding to the USB device can be determined.

[0060] The application layer is also used to match the newly added file name with the target file name to obtain a matching result.

[0061] It should be understood that the first level of matching can be filename verification, which can match the newly added filename with the target filename, that is, compare whether the newly added filename is completely consistent with the target filename included in the file list. If so, the match passes.

[0062] The application layer is also used to determine whether to add the file list corresponding to the USB device based on the matching result.

[0063] Furthermore, to implement file path verification, in this embodiment, the application layer is also used to select a target file whose filename matches the target filename from the file list when the matching result is that the newly added filename is consistent with the target filename, and determine the newly added path corresponding to the merged event and the target path corresponding to the target file; the application layer is also used to add the file list corresponding to the USB device if the newly added file corresponding to the merged event exists when the newly added path and the target path are consistent.

[0064] Understandably, if at least one filename in the target filename is exactly the same as the newly added filename, it indicates that the filename match is successful. To further verify whether the complete paths are consistent, you can first select the target files whose filenames match from the file list, and then determine the newly added path corresponding to the merged event and the target path of the target file.

[0065] It should be understood that if the newly added path is exactly the same as the target path, it indicates that the path matching is successful. Path matching can distinguish files with the same name on different devices, avoiding accidental operations. After the path matching is successful, it can be checked whether the newly added file corresponding to the merged event physically exists. If the file has been deleted but the record has not been cleared, invalid records should be cleared. If the file does exist, the file list corresponding to the USB device can be added.

[0066] In the specific implementation, refer to Figure 3 , Figure 3 This is a flowchart illustrating a triple-matching security strategy of an embodiment of the document synchronization system of this application. Figure 3 As shown, the triple-match security strategy includes: Step S10: Receive a file deletion request, with the target being / storage / usb0 / video.mp4; Step S11: Extract the target filename "video.mp4" and the complete path " / storage / usb0 / video.mp4"; Step S12: Traverse the file list, compare filenames, and find a record with the filename "video.mp4" (there may be multiple records, from usb0 and usb1 respectively); Step S13: For the records that match the filename, further compare the complete path, and only the record with the path " / storage / usb0 / video.mp4" matches successfully; Step S14: Check whether the file / storage / usb0 / video.mp4 physically exists; Step S15: If the triple verification passes, perform the file deletion operation, update the file list corresponding to the USB device, and notify the UI to refresh.

[0067] Furthermore, in this embodiment, to achieve composite signature cache isolation, the application layer is further configured to determine all files in the added file list, and determine the device identifier, complete file path, and file modification time corresponding to each file; the application layer is further configured to extract the storage device identifier from the complete file path; the application layer is further configured to concatenate the storage device identifier, the complete file path, and the file modification time, and calculate the hash value corresponding to the concatenated field; the application layer is further configured to generate a signature based on the hash value, and update the added file list based on the signature, displaying the updated file list.

[0068] Understandably, to resolve cache conflicts caused by files with the same name on multiple devices, a composite signature mechanism can be used. This mechanism can identify all files in the added file list and determine the device identifier, full file path, and file modification time for each file. The storage device identifier is then extracted from the full file path; for example, " / storage / usb0 / xxx" is extracted as "usb0", and " / storage / emulated / 0 / xxx" is extracted as "internal".

[0069] It should be understood that the storage device identifier, the full file path, and the file modification time can be concatenated, and the hash value corresponding to the concatenated field can be calculated. A signature is generated based on this hash value, which serves as the cache key. The added file list is then updated based on the signature, and the updated file list is displayed. Thus, even if two USB devices contain files with the same name, the generated signatures will be different due to the different device identifiers, resulting in separate cache entries and the display of the correct thumbnails. The same composite signature cache isolation operation can be performed on the removed file list to display the updated file list.

[0070] In the specific implementation, refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the process of composite signature cache isolation in an embodiment of the document synchronization system of this application. Figure 4 As shown, assuming there are two USB devices, namely USB0 and USB1, the signature consists of: device identifier + full file path + file modification time, which are / usb0 / video.mp4 modification time T1 and / usb1 / video.mp4 modification time T2 respectively. The signature generator includes device ID + path + time, and calculates the hash value by concatenating these three values, generating signature B and signature A, and thus displaying thumbnail B corresponding to signature B and thumbnail A corresponding to signature A. Among them, files with the same name on different devices use independent caching.

[0071] This embodiment determines the new filename corresponding to the merged event at the application layer and the target filename for the file list corresponding to the USB device. Then, it matches the new filename with the target filename to obtain the matching result. Based on the matching result, it determines whether to add the file to the USB device's file list. This embodiment completely eliminates the risk of accidental operation with files having the same name on multiple devices through a triple verification mechanism, ensuring the absolute accuracy of file operations and improving the accuracy of the final displayed file list corresponding to the USB device.

[0072] refer to Figure 5 , Figure 5 This is a flowchart illustrating the first embodiment of the document synchronization method of this application.

[0073] like Figure 5 As shown, the file synchronization method proposed in this embodiment is applied to the file synchronization systems of the above embodiments, including: Step S1: When the hardware layer detects a change in electrical signal when a USB device is inserted, it generates a hardware interrupt signal.

[0074] It is understood that the file synchronization system in this embodiment can be an Android system USB storage processing architecture, involving multiple layers of the Android system, including the hardware layer, kernel layer, native layer, framework layer, application layer, etc.

[0075] It should be understood that the hardware layer can be a USB controller, which is responsible for physical layer communication, and USB devices connect through a USB interface. When a USB device is plugged into the vehicle system's USB interface, the USB controller detects a change in electrical signals, at which point it can generate a hardware interrupt signal.

[0076] Step S2: When the kernel layer detects a hardware interrupt signal generated by the hardware layer, it identifies the device type corresponding to the USB device and creates a block device node based on the device type.

[0077] Understandably, the kernel layer can be the USB driver subsystem of the operating system kernel (Linux kernel), which can identify the device type corresponding to the USB device when it receives a hardware interrupt signal, such as a mass storage device (MassStorage Class).

[0078] It should be understood that block device drivers can create block device nodes corresponding to the device type, such as / dev / block / sda1. File system drivers, such as FAT32 / exFAT / NTFS, are responsible for resolving the file system structure.

[0079] Step S3: When the Native layer detects a new block device based on the block device node, it performs a file system mount operation according to the detected file system type.

[0080] Understandably, the Native layer refers to the low-level code layer written in C / C++ that runs directly on top of the device's operating system (usually Linux). In this embodiment, the vold (Volume Daemon) daemon in the Native layer can listen for kernel events via netlink. If a new block device is detected by listening for kernel events, the file system type can be probed.

[0081] It should be understood that file system mounting operations can be performed based on the file system type. Specifically, `vold` executes the `mount` command to mount the file system to a specified path, such as ` / storage / usbX`. The repository (libstorage) provides storage-related native interfaces.

[0082] Step S4: When the Framework layer receives the mount operation update from the Native layer, it sends a broadcast carrying the device path information corresponding to the mount operation to the application layer.

[0083] Understandably, the Framework layer refers to the application framework layer. When it receives a mount operation update from the Native layer, that is, when the StorageManagerService receives a status update from vold, it sends an ACTION_MEDIA_MOUNTED broadcast to the application layer. This broadcast carries the device path information corresponding to the mount operation.

[0084] Step S5: When the application layer receives a broadcast carrying device path information sent by the Framework layer, it displays a list of files corresponding to the USB device based on the device path information.

[0085] It should be understood that after receiving a broadcast, the USB broadcast receiver (UsbBroadcastReceiver) in the application layer can access the media data through the content resolver to extract the device path information, and then display the file list corresponding to the USB device based on the device path information.

[0086] This embodiment generates a hardware interrupt signal when a change in electrical signal is detected during USB device insertion at the hardware layer. Then, upon detecting the hardware interrupt signal, the kernel layer identifies the device type of the USB device and creates a block device node based on that type. Next, the native layer, upon detecting a new block device based on the block device node, performs a file system mount operation according to the detected file system type. Finally, upon receiving the mount operation update from the native layer, the framework layer broadcasts a message carrying the device path information to the application layer. Finally, upon receiving the broadcast message from the framework layer, the application layer displays the file list corresponding to the USB device based on the device path information. This embodiment, through a complete event transmission chain from the hardware layer, kernel layer, native layer, framework layer, and application layer, covers multiple layers of the Android system. This transmission chain enables file synchronization within the USB device, ensuring consistency between the file list and the actual state of the USB device even with frequent plugging and unplugging.

[0087] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0088] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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.

[0089] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A file synchronization system, characterized in that, The file synchronization system includes: The hardware layer is used to generate a hardware interrupt signal when a change in electrical signal is detected when a USB device is plugged in. The kernel layer is used to identify the device type corresponding to the USB device when a hardware interrupt signal is detected by the hardware layer, and to create a block device node based on the device type. The Native layer is used to perform file system mount operations based on the detected file system type when a new block device is detected based on the block device node. The Framework layer is used to send a broadcast carrying the device path information corresponding to the mount operation to the application layer when it receives the mount operation update from the Native layer. The application layer is used to display a list of files corresponding to the USB device based on the device path information when it receives a broadcast carrying device path information sent by the Framework layer.

2. The file synchronization system as described in claim 1, characterized in that, The file synchronization system also includes: The HAL layer is used to provide a unified interface for the Native layer.

3. The file synchronization system as described in claim 2, characterized in that, The application layer is also used to, upon receiving a broadcast carrying device path information sent by the Framework layer, merge events within a preset time period based on the device path information using a debouncing processor; The application layer is also used to determine whether the merged event is a mount event, and to display the file list corresponding to the USB device based on the determination result.

4. The file synchronization system as described in claim 3, characterized in that, The application layer is also used to encapsulate the device path information into a UsbEvent object when it receives a broadcast carrying device path information sent by the Framework layer; The application layer is also used to use the debouncing processor to search for whether there is an event to be processed based on the device path information in the UsbEvent object, and obtain the search result; The application layer is also used to merge events within a preset time period based on the search results.

5. The file synchronization system as described in claim 3, characterized in that, The application layer is also used to determine the final state of the merged events; The application layer is also used to determine the event type based on the final state of the event; The application layer is also used to determine whether the merged event is a mount event based on the event type, and to display the file list corresponding to the USB device based on the determination result.

6. The file synchronization system as described in claim 5, characterized in that, The application layer is also used to determine whether the merged event is a mount event based on the event type; The application layer is also used to add the file list corresponding to the USB device based on the merged event when the merged event is a mount event, and to display the added file list. The application layer is further configured to, when the merged event is an uninstallation event, remove the file list corresponding to the USB device based on the merged event, and display the removed file list.

7. The file synchronization system as described in claim 6, characterized in that, The application layer is also used to determine the new file name corresponding to the merged event, and to determine the target file name of the file list corresponding to the USB device; The application layer is also used to match the newly added file name with the target file name to obtain a matching result; The application layer is also used to determine whether to add the file list corresponding to the USB device based on the matching result.

8. The file synchronization system as described in claim 7, characterized in that, The application layer is further configured to, when the matching result is that the newly added file name is consistent with the target file name, select the target file whose file name matches from the file list, and determine the newly added path corresponding to the merged event and the target path corresponding to the target file; The application layer is further configured to, if the newly added path and the target path are the same, add the file list corresponding to the USB device if the newly added file corresponding to the merged event exists.

9. The file synchronization system as described in claim 6, characterized in that, The application layer is also used to determine all files in the added file list, and to determine the device identifier, full file path and file modification time corresponding to each file; The application layer is also used to extract the storage device identifier from the complete file path; The application layer is also used to concatenate the storage device identifier, the complete file path, and the file modification time, and calculate the hash value corresponding to the concatenated field. The application layer is also used to generate a signature based on the hash value, update the added file list based on the signature, and display the updated file list.

10. A file synchronization method, characterized in that, The file synchronization method is applied to the file synchronization system as described in any one of claims 1 to 9, and the file synchronization method includes: The hardware layer generates a hardware interrupt signal when it detects a change in electrical signal when a USB device is inserted. When the kernel layer detects a hardware interrupt signal generated by the hardware layer, it identifies the device type corresponding to the USB device and creates a block device node based on the device type. When the native layer detects a new block device based on the block device node, it performs a file system mount operation according to the detected file system type. When the Framework layer receives the mount operation update from the Native layer, it sends a broadcast carrying the device path information corresponding to the mount operation to the application layer. When the application layer receives a broadcast containing device path information sent by the Framework layer, it displays a list of files corresponding to the USB device based on the device path information.

Images