ramdisk.img is a small partition image that is mounted read-only by the kernel at boot time. It only contains /init and a few config files. It is used to start init which will mount the rest of the system images properly and run the init procedure. A Ramdisk is a standard Linux feature.
system.img is a partition image that will be mounted as / and thus contains all system binaries userdata.img is a partition image that can be mounted as /data and thus contains all application-specific and user-specific data. The build system generates these files, which can later be flashed to a real device, however the emulator uses them in a different way: - system.img is copied into a temporary file, which is used by the emulator session. So any change you make to / as root in the emulator are lost when the program exits - userdata.img is only used when you use -wipe-data. Instead, it uses ~/.android/userdata-qemu.img (on Unix) as the persistent /data partition image. Using -wipe-data simply copes the content of userdata.img into userdata-qemu.img The main idea being that the emulator should not modify system.img and userdata.img since they were generated as device images. However whether a given system.img/userdata.img set of images will run on a real device properly depends on how it was generated. For example I doubt that the ones that come with the SDK would. A few more notes: - we are currently adding "Android virtual devices" (AVD) support to the SDK. Each AVD corresponds to a directory holding persistent system images + configuration files, and refers to a specific set of kernel/ramdisk.img/system.img. Essentially the same as VMWare's virtual machines, where each one could have a different system+data installed. In the open source tree, these are called "VMs" or "AVMs" but we're currently renaming them to "AVDs" because we found the former to be confusing to a lot of people (because Dalvik too is a VM, QEMU is a VM, etc...) - it is highly likely that in the near future, device builds genearted through the source tree will not run very well in the emulator. Instead, there will be a way to build emulator-specific images designed for this purpose. The reason is we want to remove any emulator-specific hacks from the real device system images, and certain emulator features cannot be properly implemented if we don't add even more invasing changes to the system. Changes that should not appear on device images. On Sat, Feb 21, 2009 at 3:12 AM, MBethDev <[email protected]> wrote: > > Hi, > > I'm new to Android development and recently I've been playing with the > emulator and the applications, etc, and overall just getting to know > the internals of the code. My main goal though is understanding the > porting aspect of it on an actual embedded device. > > Anyway, on to my question. I noticed that when building android it > creates three img files: ramdisk.img, system.img, and userdata.img. > Can someone give an explanation what these images are? My > understanding is that these images are *emulator-specific* images to > the ram, system, userdata, respectively on the emulator, but not > necessarily "generic" images for any android-capable phones. In other > words, is it possible (at all) to upload these same images to, say, a > G1 phone and expect the same behavior I see in the emulator to be on > the G1 phone (assuming of course I use a cross-compiler for that > target phone to build the *.img files). Or are these img files solely > for emulator-purposes only? > > I apologize if this is too elementary for you guys as I'm learning > along the way here. Any input about those img files are greatly > appreciated. > > Thanks. > > MBeth > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
