AndyBig, are you talking about Lexar microSD (TransFlash) card? Do you remember what software utility you used to make an image of the original memory card? Anyway, can an image being made of bootable media with Linux-based OS (which Android is happen to be) be, like, "a bit-perfect copy" in all circumstances?
May this issue have something in common, something to do with "improperly unmounted volume with Linux file system" being back-up'ed to an image? Because I recently got similar warning message when was trying to make a back-up image of a bootable microSD from chinese portable video consoles (like Datafrog SF2000, Anbernic RG353V) via Norton Ghost utility.
In Linux, (almost) everything is a file, which You can read, write, etc. Right now Im writing on a laptop with Linux - both disk drives are files in /dev (/dev/sda and /dev/sdb) directory and having permission to read those files (usually only root id:0 and users in group disk) You can read every bit as it is. Same with SD cards and everything else (framebuffer for example). So You can make 1:1 copy. Im planning to do this (maybe today) and change SD card to decrease boot time and increase space for more files. Just copy this disk file into another file and back to another SD card.
Also Im planning to change this scope to run Linux instead of Android, as I said previously.
In this case, there are no readable files on the memory card. The file system is not recognized on it at all - both under Windows and Linux, as far as I understand from what I read on this forum. Therefore, copying data from this card is carried out by special programs that simply read all the bytes at a low level by sector.
If you are hoping to speed up loading by replacing the card with a faster one, this will not help. The read speed from the card is not a bottleneck for boot time, this has already been tested before, and I tested it too, installing a card with a stated read speed of up to 104 MB/sec
Do You have instructions or ready file(s) to do the same by us?
Everything here is actually quite simple. The .apk file is unpacked by the appktool utility, resulting in a directory with the complete contents of the application. This directory also contains the source codes of DALVIK in .smali files - a kind of assembler in the Java world. Changing the logic of the application is just possible by editing these sources. In addition, there are .xml files with descriptions of various properties, parameters, arrangement of elements in forms, etc. For example, in order to change the location and size of elements on the measurement panel, I just changed the layout description in one of the .xml files. But to change the process of drawing the border and background for these elements, I changed the source codes of the program in the .smali file.
To make it easier to navigate these Java assembler sources, you can decompile the .dex files obtained after the apktul into source codes in Java. They will not be able to compile back into the application, but they can better understand what is happening in .smali and what and how needs to be changed there to get the desired result.
After the changes have been made, the application is reassembled using the same appktool utility. After this, the resulting new application needs to be run through two more utilities - to align all internal resources of 4 bytes, and to sign the application. And you can install the resulting application on Android
I'll probably write more detailed instructions on all these steps later. In the meantime, I’m ready to answer questions if someone doesn’t succeed.