The stock Verizon system image occupies 820Mbytes, compared on the Droid-3 to the stock Gingerbread image at 213Mb, and the CM-10 Jelly Bean image at 158Mb (add 87Mb for Google apps). These are all zipped files. What bloatware are they putting into this image? Here's a list of all the apps in the stock image that have icons. Sizes are shown; items without sizes are well under 1Mb each.
The sum of the known app sizes is 100.8Mb, and it's unlikely that either the tiny apps or the ones I'm not sure of would inflate this significantly.
Digging into the image file: 820Mb compressed, 1.24Gb uncompressed (tar file). The contained objects break down as:
The system image is an ext4 filesystem. Unfortunately I was unable to
mount it -- perhaps an endian issue? ARM is big endian while Intel is little
endian. Neither could I do anything useful on the phone using ADB because
I lack root access.
Strings shows the names of all the APK files,
presumably in /system/app.
Let's try this command line:
dd if=system.img.ext4 of=system.gmi conv=swab -- Didn't help.
Later when I do have root I'll try copying the image onto the phone's /sdcard
(plenty of room) and mounting it there.
Dealing with the stock image:
Starting with COMBINATION_I535VRALG1_I535VZWALG1_743127_REV09_user_low_ship.tar.zip , see the installation page under InvisibleK's procedure for a link to a link to get this file or a similar Verizon stock image. Size 0.82Gb.
Suggested to make a separate directory to put it in. Unzip
it; the resulting file size is 1.24Gb:
You now have
which despite the extension is just a tar file. Un-tar it:
tar xf COMBINATION_I535VRALG1_I535VZWALG1_743127_REV09_user_low_ship.tar.md5
This gives you several filesystem images in EXT4 format, plus a bunch of files with .mbn extension. For example, strings in tz.mbn suggest that it is not compressed, it is involved with crypto and can use hardware encryption, and it contains several objects (X.509 certificates?) that contain pairs of Samsung Distinguished Names. The non-string content, I would not be surprised if it were compiled code for ARM (not Java bytecode).
The interesting one is system.img.ext4 which is identified as
data on an Intel system. Now transfer it to the pocket computer,
if you're doing this on an Intel host. (Using scp to dropbear:
15oKb/sec, ETA 108 mins, forget this.) (Using adb push: 4.86Mb/sec,
ETA 235 secs = 4 mins.)
mkdir /sdcard/bloatware # On phone
adb push system.img.ext4 /sdcard/bloatware/system.img.ext4 # On laptop
Try to mount the system image:
mount -o loop system.img.ext4 /data/local/tmp/mnt
losetup -f # Prints first available loop device e.g. /dev/block/loop1
losetup -r /dev/block/loop1 system.img.ext4
mount -o loop /dev/block/loop1 /data/local/tmp/mnt
However, it doesn't mount. If you specify -t ext4, it exudes
invalid argument, suggesting that there is some kind of
Try dumping the system image (on the laptop) (just the first
od -N 0x1M -t x1z system.img.ext4 > system.od
It begins with a unit of non-obvious structure running from 0 to 0002620. Then there are 0 up to 0010040.
That begins a table of entries 0100 bytes long. (Or maybe half that, but things repeat every 0100 bytes.)
The first dirent in one of the directories appears to start
at 1435120. This dir is probably /system/bin, having a lot
of symlinks to
Another important directory (root?) may start at 0010100.
Dumping the laptop's /dev/sda5 (/home, ext4) gives these insights:
File on system.img.ext4 at various offsets into the file
up to 16384. bytes (040000) does not reveal any filesystem
Clean up resources.
losetup -d /dev/block/loop1
rm system.img.ext4 # If you're done with it on the phone