Mobile storage method, device, terminal equipment and storage medium

Abstract

The present application discloses a mobile storage method, device, terminal equipment and storage medium, the method comprising: obtaining and determining the corresponding logical sector unit value of each memory according to the type information of each memory, generating the corresponding mirror according to the corresponding logical sector unit value; for each memory, replacing the mirror name of the mirror corresponding to the memory into the partition table corresponding to the memory; receiving a mirror mount instruction, the mirror mount instruction carries a partition name, and mounting the mirror indicated in the corresponding partition table according to the partition name. The problem that the file system mounting of the mobile storage solution in the prior art cannot adapt to different types of memories is solved.

Description

Technical Field

[0001] The present application relates to the technical field of data storage, and in particular to a mobile storage method, apparatus, terminal device and storage medium. Background Art

[0002] When a mobile phone is used for large-capacity mobile storage, a mobile hard disk partition needs to be allocated separately, generally named usbdisk. A vfat-format image is mounted to provide mobile storage space. In traditional solutions, the usbdisk image is generally manually generated through the image generation command, and then the manually generated image is added to the specified code path, and then packaged into the software version during the version packaging process.

[0003] In actual projects, due to different requirements and product definitions, different types of storage are often mixed in the same project and the same baseline code. When the size of the USB disk partition changes or the type of hardware storage changes, it is necessary to manually regenerate a vfat image of the corresponding size and hardware type, which makes image maintenance difficult.

[0004] In the prior art, when a mobile phone is used as a large-capacity mobile storage, the file system mounting cannot adapt to different types of storage. If there are multiple types of storage, the file system mounting will fail. Summary of the invention

[0005] The embodiments of the present application provide a mobile storage method, apparatus, terminal device and storage medium to solve the problem that the file system mounting of the traditional mobile storage solution cannot adapt to different types of storage.

[0006] The present application provides a mobile storage method, the method comprising:

[0007] Acquire and determine the corresponding logical sector unit value according to the type information of each memory, and generate the corresponding mirror according to the corresponding logical sector unit value;

[0008] For each memory, replace the image name of the image corresponding to the memory into the partition table corresponding to the memory;

[0009] An image mounting instruction is received, wherein the image mounting instruction carries a partition name, and the image indicated in the corresponding partition table is mounted according to the partition name.

[0010] Further, the acquiring and determining the corresponding logical sector unit values ​​according to the type information of each memory, and generating the corresponding images according to the corresponding logical sector unit values ​​include:

[0011] Acquire type information of each memory contained in the compiled file, and determine the corresponding logical sector unit value according to the type information of each memory;

[0012] The image compilation interface is added to the compilation kernel droidcore. During the system compilation process of the compilation kernel droidcore, the corresponding images are generated according to the logical sector unit values ​​corresponding to each memory.

[0013] Furthermore, the method further comprises:

[0014] If it is determined that the compiled file does not contain the type information of the memory, images corresponding to the respective logical sector unit values ​​are generated respectively according to the pre-specified logical sector unit values.

[0015] Further, generating the corresponding mirrors according to the logical sector unit values ​​corresponding to each memory includes:

[0016] For each memory, the actual space storage value of each partition of the memory is obtained; and according to the actual space storage value of each partition and the logical sector unit value corresponding to the memory, the mirror corresponding to each partition is generated.

[0017] Further, for each memory, replacing the image name of the image corresponding to the memory into the partition table corresponding to the memory includes:

[0018] For each of the memories, read the partition table corresponding to the memory, determine the offset position of the image name field by searching for keywords in the partition table, and replace the image name of the image corresponding to the memory into the image name field of the partition table corresponding to the memory according to the offset position.

[0019] Furthermore, the method further comprises:

[0020] When a formatting instruction is received, the total number of sectors corresponding to each memory is obtained and determined according to the actual space storage value and the logical sector unit value of each memory; and formatting is performed according to the total number of sectors corresponding to each memory.

[0021] Further, determining the total number of sectors corresponding to each memory according to the actual space storage value and the logical sector unit value of each memory includes:

[0022] The ratio of the actual space storage value of each memory to the logical sector unit value is used as the total number of sectors corresponding to each memory.

[0023] On the other hand, an embodiment of the present application provides a mobile storage device, the device comprising:

[0024] An acquisition module, used for acquiring and determining the corresponding logical sector unit value according to the type information of each memory, and generating the corresponding mirror image according to the corresponding logical sector unit value;

[0025] An update module, used for replacing, for each memory, the image name of the image corresponding to the memory into the partition table corresponding to the memory;

[0026] The processing module is used to receive an image mounting instruction, wherein the image mounting instruction carries a partition name, and mounts the image indicated in the corresponding partition table according to the partition name.

[0027] The acquisition module is specifically used to obtain the type information of each memory contained in the compilation file, and determine the corresponding logical sector unit value according to the type information of each memory; add the image compilation interface to the compilation kernel droidcore, and during the system compilation process of the compilation kernel droidcore, generate the corresponding image according to the corresponding logical sector unit value of each memory.

[0028] The acquisition module is further configured to generate images corresponding to respective logical sector unit values ​​according to pre-specified logical sector unit values ​​if it is determined that the compiled file does not contain the type information of the memory.

[0029] The acquisition module is specifically used to acquire the actual space storage value of each partition of each memory for each memory; and generate the mirror corresponding to each partition according to the actual space storage value of each partition and the logical sector unit value corresponding to the memory.

[0030] The update module is specifically used to read the partition table corresponding to each memory, determine the offset position of the image name field by searching the keyword in the partition table, and replace the image name of the image corresponding to the memory into the image name field of the partition table corresponding to the memory according to the offset position.

[0031] The processing module is also used to, when receiving a formatting instruction, obtain and determine the total number of sectors corresponding to each memory according to the actual space storage value and the logical sector unit value of each memory; and format according to the total number of sectors corresponding to each memory.

[0032] The processing module is specifically used to use the ratio of the actual space storage value of each memory to the logical sector unit value as the total number of sectors corresponding to each memory.

[0033] On the other hand, an embodiment of the present application provides a terminal device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0034] Memory, used to store computer programs;

[0035] The processor is used to implement any of the method steps described above when executing the program stored in the memory.

[0036] On the other hand, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, any of the method steps described above is implemented.

[0037] The embodiments of the present application provide a mobile storage method, apparatus, terminal device and storage medium, the method comprising: obtaining and determining the corresponding logical sector unit value of each memory according to the type information of each memory, generating the corresponding image according to the corresponding logical sector unit value; for each memory, replacing the image name of the image corresponding to the memory into the partition table corresponding to the memory; receiving an image mounting instruction, the image mounting instruction carrying a partition name, and mounting the image indicated in the corresponding partition table according to the partition name.

[0038] The above technical solution has the following advantages or beneficial effects:

[0039] In the embodiment of the present application, the type information of the memory is first obtained, and the corresponding logical sector unit value is determined, and then the image corresponding to each type of memory is generated according to the logical sector unit value, and the image name of the generated image is replaced in the partition table corresponding to the memory. When mounting the image, the partition name carried in the image mounting instruction is obtained, and then the image indicated in the corresponding partition table is mounted according to the partition name, so as to be compatible with different types of memories, solving the problem that the file system mounting of the mobile storage solution in the prior art cannot adapt to different types of memories. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0041] Figure 1 A schematic diagram of a mobile storage process provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of another mobile storage process provided by an embodiment of the present application;

[0043] Figure 3 A schematic diagram of another mobile storage process provided in an embodiment of the present application;

[0044] Figure 4 for Figure 4 A schematic diagram of the image generation process provided in an embodiment of the present application;

[0045] Figure 5 A schematic diagram of a process for replacing an image name into a partition table provided in an embodiment of the present application;

[0046] Figure 6 An example diagram of image name replacement provided in an embodiment of the present application;

[0047] Figure 7 Another example diagram of image name replacement provided in an embodiment of the present application;

[0048] Figure 8 A detailed flow chart of the mobile storage process provided in the embodiment of the present application;

[0049] Fig. 9 A schematic diagram of the image generation process provided in an embodiment of the present application;

[0050] Fig.10 A schematic diagram of the image name update adaptation process provided in an embodiment of the present application;

[0051] Fig.11 A schematic diagram of the image name replacement process provided in an embodiment of the present application;

[0052] Fig.12 A schematic diagram of the formatting process provided in an embodiment of the present application;

[0053] Fig.13 A schematic diagram of the structure of a mobile storage device provided in an embodiment of the present application;

[0054] Fig.14 A schematic diagram of the terminal device structure provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] The present application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present application.

[0056] Figure 1A schematic diagram of a mobile storage process provided in an embodiment of the present application, the process includes the following steps:

[0057] S101: Acquire and determine the corresponding logical sector unit value according to the type information of each memory, and generate the corresponding mirror according to the corresponding logical sector unit value.

[0058] S102: For each memory, replace the image name of the image corresponding to the memory into the partition table corresponding to the memory.

[0059] S103: receiving an image mounting instruction, wherein the image mounting instruction carries a partition name, and mounting the image indicated in the corresponding partition table according to the partition name.

[0060] The mobile storage method provided in the embodiment of the present application is applied to a terminal device, which may be a PC, a mobile phone, a tablet computer, etc. Specifically, a solution is provided for implementing large-capacity storage of terminal devices using adaptive storage devices of different hardware types.

[0061] In the embodiment of the present application, the terminal device first obtains the type information of each memory, and there is a corresponding relationship between the type information of each memory and the logical sector unit value, and the type information of each memory is determined according to the corresponding relationship to determine the corresponding logical sector unit value. For example, the type information of each memory is obtained as UFS memory and EMMC memory, and the logical sector unit value corresponding to the UFS memory is determined to be 4096 bytes according to the corresponding relationship, and the logical sector unit value corresponding to the EMMC memory is determined to be 512 bytes.

[0062] After determining the type information of each memory and determining the corresponding logical sector unit value, the corresponding image is generated according to the corresponding logical sector unit value. The logical sector unit value needs to be carried in the image generation instruction. Therefore, after determining the type information of each memory and determining the corresponding logical sector unit value, the corresponding logical sector unit value is carried in the image generation instruction, thereby generating the corresponding image of each memory.

[0063] Each storage has a corresponding partition table. When mounting an image, it is necessary to obtain the corresponding image according to the image name in the partition table and perform the mounting. Therefore, after generating the image corresponding to each storage, for each storage, replace the image name of the image corresponding to the storage into the partition table corresponding to the storage. In this way, after receiving the image mounting instruction, obtain the partition name carried in the image mounting instruction, and then determine the image indicated by the corresponding partition table according to the partition name, and perform the mounting task.

[0064] In the embodiment of the present application, the type information of the memory is first obtained, and the corresponding logical sector unit value is determined, and then the image corresponding to each type of memory is generated according to the logical sector unit value, and the image name of the generated image is replaced in the partition table corresponding to the memory. When mounting the image, the partition name carried in the image mounting instruction is obtained, and then the image indicated in the corresponding partition table is mounted according to the partition name, so as to be compatible with different types of memories, solving the problem that the file system mounting of the mobile storage solution in the prior art cannot adapt to different types of memories.

[0065] In the embodiment of the present application, in order to solve the file system image differences introduced by the different logical sector unit values ​​corresponding to various types of memories, the embodiment of the present application adds a generation mechanism for the specified USB disk image in the Android system full compilation stage. Specifically, the acquisition and determination of the corresponding logical sector unit value of each memory according to the type information of each memory, and the generation of the corresponding image according to the corresponding logical sector unit value include:

[0066] Acquire type information of each memory contained in the compiled file, and determine the corresponding logical sector unit value according to the type information of each memory;

[0067] The image compilation interface is added to the compilation kernel droidcore. During the system compilation process of the compilation kernel droidcore, the corresponding images are generated according to the logical sector unit values ​​corresponding to each memory.

[0068] Figure 2 A schematic diagram of a mobile storage process provided in an embodiment of the present application, the process includes:

[0069] S201: Acquire type information of each memory included in a compilation file, and determine a corresponding logical sector unit value according to the type information of each memory.

[0070] S202: adding the image compilation interface to the compilation kernel droidcore, and generating the corresponding images according to the logical sector unit values ​​corresponding to each memory during the system compilation process of the compilation kernel droidcore.

[0071] S203: For each storage device, replace the image name of the image corresponding to the storage device into the partition table corresponding to the storage device.

[0072] S204: receiving an image mounting instruction, wherein the image mounting instruction carries a partition name, and mounting the image indicated in the corresponding partition table according to the partition name.

[0073] The terminal device first obtains the compilation file, obtains the type information of each memory contained in the compilation file by parsing the compilation file, and then determines the type information of each memory to determine the corresponding logical sector unit value according to the corresponding relationship between the type information of each memory and the logical sector unit value. In the compilation file, the image compilation interface is added to the compilation kernel droidcore, so that the image can be automatically generated during the entire compilation process of the Android system. During the system compilation process of the compilation kernel droidcore, the corresponding images are generated according to the corresponding logical sector unit values ​​of each memory.

[0074] For example, obtain a compilation file, and obtain the type information of the memory contained in the compilation file by parsing the compilation file, which is UFS memory and EMMC memory, determine that the logical sector unit value corresponding to the UFS memory is 4096 bytes, and determine that the logical sector unit value corresponding to the EMMC memory is 512 bytes. Add the image compilation interface to the compilation kernel droidcore, and during the system compilation process of the compilation kernel droidcore, generate the image corresponding to the UFS memory according to the logical sector unit value of 4096 bytes, and generate the image corresponding to the EMMC memory according to the logical sector unit value of 512 bytes.

[0075] In one embodiment, the method further comprises:

[0076] If it is determined that the compiled file does not contain the type information of the memory, images corresponding to the respective logical sector unit values ​​are generated respectively according to the pre-specified logical sector unit values.

[0077] Figure 3 A schematic diagram of a mobile storage process provided in an embodiment of the present application, the process includes:

[0078] S301: If it is determined that the compiled file does not contain the type information of the memory, images corresponding to the respective logical sector unit values ​​are generated respectively according to the pre-specified logical sector unit values.

[0079] S302: For each storage device, replace the image name of the image corresponding to the storage device into the partition table corresponding to the storage device.

[0080] S303: Receive an image mounting instruction, the image mounting instruction carrying a partition name, and mount the image indicated in the corresponding partition table according to the partition name.

[0081] If the type information of the memory is not included in the compilation file, a variety of different images are generated according to common logical sector unit values, which are pre-specified logical sector unit values, such as 4096 bytes, 512 bytes, 2048 bytes, etc. Images corresponding to 4096 bytes, 512 bytes, and 2048 bytes are generated respectively. Specifically, the image compilation interface is added to the compilation kernel droidcore. During the compilation of the system by the compilation kernel droidcore, an image corresponding to the UFS memory is generated according to the logical sector unit value of 4096 bytes, an image corresponding to the EMMC memory is generated according to the logical sector unit value of 512 bytes, and an image corresponding to another common memory is generated according to the logical sector unit value of 2048 bytes.

[0082] The memory generally includes multiple partitions. If the generated image is a vfat type image, it is necessary to generate a corresponding image for each partition in the memory.

[0083] Specifically, Figure 4 A schematic diagram of a mirror generation process provided in an embodiment of the present application, the process includes:

[0084] S401: For each memory, obtain the actual space storage value of each partition of the memory.

[0085] S402: Generate a mirror corresponding to each partition according to the actual space storage value of each partition and the logical sector unit value corresponding to the memory.

[0086] For each memory, determine the actual space storage value of each partition of the memory. The actual space storage value of each partition of the memory may be different, and the logical sector unit value of each partition is the same. For each partition, generate the image corresponding to the partition according to the actual space storage value of the partition and the logical sector unit value corresponding to the memory. The number of sectors of the partition can be determined according to the ratio of the actual space storage value of the partition and the logical sector unit value corresponding to the memory. The number of sectors of the partition and the logical sector unit value corresponding to the memory are carried in the image generation instruction, and then the image corresponding to the partition is generated.

[0087] Figure 5 A schematic diagram of a process for replacing an image name into a partition table provided in an embodiment of the present application, the process comprising:

[0088] S501: For each memory, read a partition table corresponding to the memory.

[0089] S502: Determine the offset position of the image name field by searching for a keyword in the partition table.

[0090] S503: replacing the image name of the image corresponding to the storage device into the image name field of the partition table corresponding to the storage device according to the offset position.

[0091] Each storage has a corresponding partition table, which contains the field information of each partition in the storage. The offset position of the image name field of each partition can be determined by keyword search. If the images of each partition are the same, the image name is replaced into the image name field of each partition in the partition table according to the offset position of the image name field of each partition. If the images of each partition are different, the image name of the image corresponding to each partition is replaced into the image name field of each corresponding partition according to the offset position of the image name field of each partition.

[0092] like Figure 6 As shown, for example: the EMMC memory includes 4 partitions, namely, partition A, partition B, partition C and partition D. The partition table corresponding to the EMMC memory contains field information of partition A, partition B, partition C and partition D respectively. Through keyword search, the offset positions of the image name fields of partition A, partition B, partition C and partition D are determined respectively. If the images corresponding to partition A, partition B, partition C and partition D are all image m. Then, according to the offset positions of the image name fields corresponding to partition A, partition B, partition C and partition D respectively, the image name of image m is replaced into the image name fields of partition A, partition B, partition C and partition D.

[0093] like Figure 7 As shown, for example: the EMMC memory includes 4 partitions, namely, partition A, partition B, partition C and partition D. The partition table corresponding to the EMMC memory contains field information of partition A, partition B, partition C and partition D respectively. Through keyword search, the offset positions of the image name fields of partition A, partition B, partition C and partition D are determined respectively. If the image corresponding to partition A is generated as image a, the image corresponding to partition B is image b, the image corresponding to partition C is image c, and the image corresponding to partition D is image d. Then, according to the offset position of the image name field, the image name of image a is replaced with the image name field of partition A, the image name of image b is replaced with the image name field of partition B, the image name of image c is replaced with the image name field of partition C, and the image name of image d is replaced with the image name field of partition D.

[0094] Figure 8 A detailed flow chart of the mobile storage process provided in the embodiment of the present application, the process includes:

[0095] S801: For each memory, obtain the actual space storage value of each partition of the memory; and generate a mirror corresponding to each partition according to the actual space storage value of each partition and the logical sector unit value corresponding to the memory.

[0096] S802: For each of the memories, read the partition table corresponding to the memory, determine the offset position of the image name field by searching for a keyword in the partition table, and replace the image name of the image corresponding to the memory into the image name field of the partition table corresponding to the memory according to the offset position.

[0097] S803: Receive an image mounting instruction, the image mounting instruction carrying a partition name, and mount the image indicated in the corresponding partition table according to the partition name.

[0098] In the embodiment of the present application, the method further includes:

[0099] When a formatting instruction is received, the total number of sectors corresponding to each memory is obtained and determined according to the actual space storage value and the logical sector unit value of each memory; and formatting is performed according to the total number of sectors corresponding to each memory.

[0100] Specifically, the ratio of the actual space storage value of each memory to the logical sector unit value is used as the total number of sectors corresponding to each memory.

[0101] The mobile storage process provided in the embodiment of the present application is described in detail below with reference to the accompanying drawings.

[0102] Considering that in actual projects, due to different requirements and product definitions, different types of storage are often mixed in the same project and the same baseline code. When the size of the USB disk partition changes or the type of hardware storage changes, it is necessary to manually regenerate a vfat image of the corresponding size and hardware type, which makes image maintenance difficult. In order to facilitate development management and realize the compatibility of software versions with USB disk images of different hardware types, the mobile storage solution provided by the embodiment of the present application is introduced, so that USB disk is generated with Android compilation, without the need for manual generation in advance, and the corresponding image is generated according to the configured hardware type, so that the same version package can adapt to USB disk partitions of multiple hardware types.

[0103] When a mobile phone divides storage space for large-capacity mobile storage, different hardware types of storage (such as eMMC, UFS, etc.) need to mount different vfat file system images due to different logical sector unit values. The traditional solution of the Android platform cannot adapt to different storage types when formatting vfat.

[0104] In traditional solutions, when some file systems are mounted, the corresponding file system image needs to match the actual hardware memory type, otherwise the mount will fail. For example: a sector on the ufs memory hardware is 4096 bytes, while a sector on the emmc memory is 512 bytes. If a vfat format image is generated, the actual physical sector size needs to be specified when the image is generated, that is, the actual space storage value is indicated. When formatting a file system partition, it is generally necessary to specify the total number of sectors to confirm the size to be formatted. The Android platform vfat formatting uses the number of sectors calculated based on 512 bytes as the total number of sectors. When the sector unit size of the hardware platform is not 512 bytes (such as a ufs device), the partition size will be abnormal after formatting, and it will not be compatible with memories with different logical sector unit values.

[0105] The embodiment of the present application provides a large-capacity mobile storage image generation, loading and formatting solution that is adaptive to different hardware types. In the Android full compilation stage, a file system image of various hardware is generated according to the actual memory type information, providing a basis for the successful mounting of the image. In the partition formatting stage, the actual corresponding total number of file system sectors is calculated according to the total byte size of the partition (actual space storage value) and the actual logical sector unit value to ensure adaptive adaptation to different memory hardware types.

[0106] 1. Image generation solution.

[0107] When a mobile phone is used for large-capacity mobile storage, a space for large-capacity mobile storage will be allocated in the partition table, generally named usbdisk. This partition generally needs to mount a file system image of the vfat / exfat type, but due to different hardware storage types, the mount images required to be generated for different hardware storages are different. For example: when the storage hardware is ufs, because the value of the logical sector unit of the ufs storage is 4096 bytes, when using mkfs.vfat to generate a vfat format image, it is necessary to specify the logical sector unit value as 4096; and when the storage hardware is emmc, because the value of the logical sector unit of emmc is 512 bytes, when generating a file system image, it is necessary to specify the logical sector unit value as 512. The same series of mobile phones may use both ufs and emmc. In this case, the mobile phone version needs to be able to adapt to different storage types to avoid the problem of mounting failure caused by the mismatch between the file system image and the storage logical sector unit value. This problem will cause the large-capacity mobile storage function to fail.

[0108] In order to solve the file system image differences caused by the different values ​​of logical sector units of various types of memory, the embodiment of the present application adds a generation mechanism for a specified USB disk image during the full compilation stage of the Android system. In the compilation file, the USB disk image compilation interface is added to Droidcore to realize the automatic generation function of the USB disk image during the full compilation process of the Android system.

[0109] Fig. 9 A schematic diagram of the image generation process provided in the embodiment of the present application. The compilation of the usbdisk image is implemented through the mkfs.vfat command, but it is necessary to dynamically configure the logical sector unit value according to the actual memory type to generate the correct image. When the memory is ufs, SECTOR_SIZE=4096, when the memory is emmc, SECTOR_SIZE=512, when the memory is other types, SECTOR_SIZE=2048. If a 100M image is generated, it can be generated through the mkfs.vfat-n "Internal SD"-F 32-C out / usbdisk.img102400-S$SECTOR_SIZE command. Fig. 9 As shown, the image generation process includes: full compilation of the Android system version, compilation to generate a vfat / exfat image, judging whether to configure the storage type: ufs type, emmc type or other types, if the ufs type is configured, generating an image that supports the ufs logical sector unit value: mkfs.vfat-C udisk_4096.img-S 4096; if the emmc type is configured, generating an image that supports the emmc logical sector unit value: mkfs.vfat-C udisk_512.img-S 512; if other types are configured, generating an image that supports other logical sector unit values: mkfs.vfat-C udisk_XXXX.img-S XXXX; if the storage type is not defined, generating multiple images that support various common logical sector unit values: mkfs.vfat-C udisk_4096.img-S 4096, mkfs.vfat-C udisk_512.img-S 512, mkfs.vfat –C udisk_2048.img -S 2048 and so on.

[0110] If the compilation file in the project (such as BoardConfig.mk for Android platform) has specified the specific storage type information, only a unique image will be generated for the specific storage type; if the specific storage type information is not specified in the project, multiple different usbdisk images will be generated based on the common logical sector unit values. The specific logical sector unit value is specified by the -S parameter in mkfs.vfat. For example, for ufs storage, you need to specify mkfs.vfat-S4096, and for emmc storage, you need to specify mkfs.vfat-S 512. For storage with other logical sector unit values, you need to specify the -S parameter according to the actual size.

[0111] 2. Image loading solution.

[0112] The first phase of image generation in the embodiment of the present application (generating an adapted USB disk image with the Android full system compilation) can only ensure that an image corresponding to the logical sector unit value is generated according to the hardware type, but whether the correct image is loaded into the memory still needs to be specified through the partition table. For different types of memory, different partition tables need to be selected when downloading the version. To ensure that the images of the matching memory types are configured in different types of partition tables, the corresponding USB disk image name needs to be replaced in the partition table corresponding to each memory type during the version packaging stage to ensure that the correct image is downloaded during the flashing stage.

[0113] After the partition table is generated, you need to add the usbdisk image name that supports different logical sector unit values ​​to the partition table. For projects that specify specific hardware, you can only replace the corresponding partition table. For projects that do not specify specific hardware and require full compatibility, you need to package the corresponding image and replace the image name.

[0114] Fig.10 A schematic diagram of the image name update adaptation process provided in the embodiment of the present application is as follows: Fig.10As shown, for the full compatibility, in the image generation stage, the generated images are udisk_4096.img, udisk_512.img, udisk_2048.img, etc. When adapting the partition table, a) in the ufs partition table partition_ufs.xml, find the usbdisk partition name, locate the position, and replace the corresponding partition image name field with udisk_4096.img; b) in the emmc partition table partition_emmc.xml, find the usbdisk partition name, locate the position, and replace the corresponding partition image name field with udisk_512.img; c) for the storage partition table partition_XXXB.xml of other unit sector sizes, XXX corresponds to the specific unit sector size, find the usbdisk partition name, locate the position, and replace the corresponding partition image name field with udisk_xxx.img, such as the image name corresponding to partition_2048B.xml should be replaced with udisk_2048.img. like Fig.10 As shown, the partition table image name is updated and adapted, and the storage type is determined to be ufs type, emmc type or other type. If the storage type is ufs type, the image configuration to be loaded in the ufs partition table is the vfat / exfat image corresponding to ufs: udisk_4096.img; if the storage type is emmc type, the image configuration to be loaded in the emmc partition table is the vfat / exfat image corresponding to emmc: udisk_512.img; if the storage type is other types, the image configuration to be loaded in the corresponding partition table is the vfat / exfat image of the corresponding sector unit size, such as: udisk_2048.img.

[0115] Fig.11 A schematic diagram of the image name replacement process provided in the embodiment of the present application is as follows: Fig.11 As shown, the specific method for replacing the partition table image name is as follows: read the partition table, determine whether the row content contains usbdisk, if so, read the single row content, confirm the offset position of the partition image field, and replace the partition table with the adapted udisk_xxx.img image name. If the row content does not contain usbdisk, continue to determine whether the next row content contains usbdisk. Specifically, read the partition table partition_xxx.xml, search for the keyword usbdisk by row, record the corresponding row number after finding it, read the single row content, find the offset position of the partition name definition field, and fill the corresponding image udisk_xxx.img name into the field according to the offset position.

[0116] In the embodiment of the present application, after the adaptation of the image name loaded in different types of partition tables is implemented, in the device startup image mounting process, in order to ensure that there is no problem with the mounting, it is necessary to ensure that the mount command specifies the device by means of the partition name: / dev / block / by-name / usbdisk rather than by the specific block device name / devices / platform / soc / 4744000.sdhci / …, thereby ensuring that the same mount command is compatible with different storage devices during the mounting stage.

[0117] The file system is usually mounted through "mount-t [file system type] [block device name] [mount destination path]", such as vfat format mounting: mount–t vfat / dev / block / by-name / usbdisk / storage / sdcard. / dev / block / by-name / usbdisk is the corresponding block device name, usbdisk is the specific partition name, and the usbdisk.img of the corresponding file system type needs to be downloaded to this partition, such as vfat type usbdisk.img.

[0118] 3. Image formatting solution.

[0119] Generally, a product will divide the memory into many different partitions, such as data partition and USB disk partition. Data partition is what we call mobile phone storage space in daily life, and USB disk partition is a space in the mobile phone that is specially used as a mobile hard disk space, that is, when the mobile phone is plugged into the computer, the mobile phone will be displayed as a USB disk and can be used directly as a USB disk.

[0120] After the usbdisk partition image is mounted normally at boot, the user will need the formatting function to clear all the contents in the usbdisk partition. The vfat / exfat formatting function needs to specify the total number of sectors of the actual partition to achieve full disk formatting, but the total number of sectors obtained by the Android native platform is obtained through the BLKGETSIZE interface of ioctl based on the number of sectors of 512 bytes. For example, if the usbdisk partition size is 100GB, the total sector size dev_size variable value read by ioctl (" / dev / block / by-name / usbdisk", BLKGETSIZE, &dev_size) is: 100*1024*1024*1024 / 512=209715200. According to the number of sectors obtained by this method, after formatting a non-512-byte storage, it will cause problems such as abnormal space size.

[0121] Android natively obtains the total number of sectors through the BLKGETSIZE interface. The Chinese meaning of BLKGETSIZE is "get the number of sectors in 512 bytes". The specific implementation of BLKGETSIZE reads the actual space storage value from the GPT global unique identifier disk partition table header, divides the actual space storage value by 512, and assigns the result as the calculated total number of sectors as the return value to dev_size.

[0122] The native platform solution is not compatible with memories with different logical sector unit values. To achieve compatibility with different memories, it is necessary to obtain the actual space storage value and the logical sector unit value, and calculate the real and effective total number of sectors based on the obtained values.

[0123] When the vfat file system image is generated, it is necessary to specify the actual space storage value and the logical sector unit value. This data will be written into the image data header. In the image generation stage of the embodiment of the present application, different hardware has ensured the correct file system image generated. By reading the data header in the boot sector, the actual space storage value and the logical sector unit value of the corresponding hardware can be obtained. For example: a 100GB usbdisk partition on a ufs memory, after the dynamic image generation process, generates an image as udisk_4096.img, and the logical sector unit value read in the image boot sector is 4096 bytes, and the actual space storage value is 100GB. A 100GB usbdisk partition on an emmc memory, after the dynamic image generation process, generates an image as udisk_512.img, and the logical sector unit value read in the image boot sector is emmc 512 bytes, and the actual space storage value is 100GB.

[0124] The method to calculate the total number of sectors of different types of storage is to divide the actual space storage value by the logical sector unit value. For example: for ufs storage, the total number of sectors corresponding to a 100GB usbdisk partition should be 100*1024*1024*1024 / 4096, while for emmc storage it should be 100*1024*1024*1024 / 512. The actual space storage value in bytes can be read from the boot sector through ioctl BLKGETSIZE64, and the logical sector unit value configured in the image compilation phase can be read from the boot sector through ioctl BLKSSZGET. Based on the obtained values, the real and effective total number of physical sectors of different storage can be calculated, thereby achieving compatibility in the formatting phase.

[0125] Among them, ioctl: the abbreviation of input / output control, is a function in the device driver to manage the I / O channel of the device. Ioctl is a system call dedicated to device input and output operations. The call passes in a request code related to the device and calls different functions according to the request code. For example, BLKGETSIZE64 is a request code. BLKGETSIZE64: Get the actual space storage value in bytes. BLKSSZGET: Get the logical sector unit value.

[0126] Fig.12 A schematic diagram of the formatting process provided in the embodiment of the present application is shown in FIG. Fig.12 As shown in the figure, vfat / exfat image formatting, the actual space storage value in partition bytes is obtained through ioctl BLKGETSIZE64, and the logical sector unit value specified in the image generation process is obtained through ioctlBLKSSZGET. The total number of sectors = actual space storage value / logical sector unit value, and the actual space is formatted according to the total number of sectors.

[0127] Fig.13 A schematic diagram of the structure of a mobile storage device provided in an embodiment of the present application, the device comprises:

[0128] The acquisition module 131 is used to acquire and determine the corresponding logical sector unit value according to the type information of each memory, and generate the corresponding image according to the corresponding logical sector unit value;

[0129] An updating module 132 is used to replace, for each memory, the image name of the image corresponding to the memory into the partition table corresponding to the memory;

[0130] The processing module 133 is used to receive an image mounting instruction, wherein the image mounting instruction carries a partition name, and mounts the image indicated in the corresponding partition table according to the partition name.

[0131] The acquisition module 131 is specifically used to obtain the type information of each memory contained in the compilation file, and determine the corresponding logical sector unit value according to the type information of each memory; add the image compilation interface to the compilation kernel droidcore, and during the system compilation process of the compilation kernel droidcore, generate the corresponding image according to the corresponding logical sector unit value of each memory.

[0132] The acquisition module 131 is further configured to generate images corresponding to respective logical sector unit values ​​according to pre-specified logical sector unit values ​​if it is determined that the compiled file does not contain the type information of the memory.

[0133] The acquisition module 131 is specifically used to acquire the actual space storage value of each partition of each memory for each memory; and generate the mirror corresponding to each partition according to the actual space storage value of each partition and the logical sector unit value corresponding to the memory.

[0134] The update module 132 is specifically used to read the partition table corresponding to each memory, determine the offset position of the image name field by searching the keyword in the partition table, and replace the image name of the image corresponding to the memory into the image name field of the partition table corresponding to the memory according to the offset position.

[0135] The processing module 133 is also used to, when receiving a formatting instruction, obtain and determine the total number of sectors corresponding to each memory according to the actual space storage value and the logical sector unit value of each memory; and format according to the total number of sectors corresponding to each memory.

[0136] The processing module 133 is specifically configured to use the ratio of the actual space storage value of each memory to the logical sector unit value as the total number of sectors corresponding to each memory.

[0137] The present application also provides a terminal device, such as Fig.14 As shown, it includes: a processor 141, a communication interface 142, a memory 143 and a communication bus 144, wherein the processor 141, the communication interface 142, and the memory 143 communicate with each other through the communication bus 144; a computer program is stored in the memory 143, and when the program is executed by the processor 141, the processor 141 executes any of the above method steps.

[0138] The communication bus mentioned in the terminal device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0139] The communication interface 142 is used for communication between the above terminal device and other devices.

[0140] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0141] The above-mentioned processor can be a general-purpose processor, including a central processing unit, a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, etc.

[0142] An embodiment of the present application further provides a computer storage readable storage medium, wherein the computer readable storage medium stores a computer program executable by a terminal device, and when the program runs on the terminal device, the terminal device executes any method step.

[0143] Although the preferred embodiments of the present application have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0144] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A mobile storage method, characterized in that: The method comprises: Acquire and determine the corresponding logical sector unit value according to the type information of each memory, and generate the corresponding mirror according to the corresponding logical sector unit value; For each memory, replace the image name of the image corresponding to the memory into the partition table corresponding to the memory; Receive an image mounting instruction, the image mounting instruction carrying a partition name, and mount the image indicated in the corresponding partition table according to the partition name; For each memory, replacing the image name of the image corresponding to the memory into the partition table corresponding to the memory includes: For each of the memories, read the partition table corresponding to the memory, determine the offset position of the image name field by searching for keywords in the partition table, and replace the image name of the image corresponding to the memory into the image name field of the partition table corresponding to the memory according to the offset position.

2. The method according to claim 1, characterized in that The obtaining and determining the corresponding logical sector unit value according to the type information of each memory, and generating the corresponding mirror according to the corresponding logical sector unit value comprises: Acquire type information of each memory contained in the compiled file, and determine the corresponding logical sector unit value according to the type information of each memory; The image compilation interface is added to the compilation kernel droidcore. During the system compilation process of the compilation kernel droidcore, the corresponding images are generated according to the logical sector unit values ​​corresponding to each memory.

3. The method according to claim 2, characterized in that The method further comprises: If it is determined that the compiled file does not contain the type information of the memory, images corresponding to the respective logical sector unit values ​​are generated respectively according to the pre-specified logical sector unit values.

4. The method according to claim 1 or 2, characterized in that: Generating the corresponding mirrors according to the logical sector unit values ​​corresponding to each memory includes: For each memory, the actual space storage value of each partition of the memory is obtained; and according to the actual space storage value of each partition and the logical sector unit value corresponding to the memory, the mirror corresponding to each partition is generated.

5. The method according to claim 1, characterized in that The method further comprises: When a formatting instruction is received, the total number of sectors corresponding to each memory is obtained and determined according to the actual space storage value and the logical sector unit value of each memory; and formatting is performed according to the total number of sectors corresponding to each memory.

6. The method according to claim 5, characterized in that Determining the total number of sectors corresponding to each memory according to the actual space storage value and the logical sector unit value of each memory includes: The ratio of the actual space storage value of each memory to the logical sector unit value is used as the total number of sectors corresponding to each memory.

7. A mobile storage device, characterized in that: The device comprises: An acquisition module, used for acquiring and determining the corresponding logical sector unit value according to the type information of each memory, and generating the corresponding mirror image according to the corresponding logical sector unit value; An update module, used for replacing, for each memory, the image name of the image corresponding to the memory into the partition table corresponding to the memory; A processing module, configured to receive an image mounting instruction, wherein the image mounting instruction carries a partition name, and mount the image indicated in the corresponding partition table according to the partition name; The update module is specifically used to read the partition table corresponding to each memory, determine the offset position of the image name field by searching the keyword in the partition table, and replace the image name of the image corresponding to the memory into the image name field of the partition table corresponding to the memory according to the offset position.

8. A terminal device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1 to 6 when executing a program stored in a memory.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1 to 6 are implemented.

Images