Questions on ramdisk, userdata, and system img files

[MBethDev]

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

[David Turner]

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.

[MBethDev]

Thanks David. Very informative.

So say I modified the android code, added some functionality or tweaks
in there, build and generate those three images (ramdisk, system,
userdata), if I want to test or verify these changes on a real device
(say a G1 phone), all I have to do is upload or flash these img files
onto the G1 phone?

MBeth

On Feb 21, 12:27 am, David Turner <di...@android.com> wrote:
> 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

> > MBeth- Hide quoted text -
>
> - Show quoted text -

[David Turner]

On Sun, Feb 22, 2009 at 6:04 AM, MBethDev <mbet...@gmail.com> wrote:

Thanks David.  Very informative.

So say I modified the android code, added some functionality or tweaks
in there, build and generate those three images (ramdisk, system,
userdata), if I want to test or verify these changes on a real device
(say a G1 phone), all I have to do is upload or flash these img files
onto the G1 phone?

absolutely, but there may be additionnal packaging involved (which already is handled by the build system).

Essentially, the kernel image + ramdisk will be combined into a boot.img, which may include other things I'm

not aware of.

Then you would use the fastboot command to flash these partitions to a real device. I can't really tell you exactly

how all of this happens though. Here's how I reflash the system image on my device:lunch

 

. build/ensetup.sh    -- setup environment

lunch dream-eng      -- setup Dream build + engineering options (larger but better for debugging)

make -j8                 -- rebuild on a Quad-core machine

-- reboot phone in bootloader mode  (press back while turning on the phone with the EndCall button)

-- connect it through USB, see the message that says "SERIAL" turn into "FASTBOOT"

fastboot flash system out/target/product/dream/system.img

fastboot reboot

for radical changes to the system, you might want to use the "-w" option to fastboot that clears the data partition

or you could do a: fastboot flash data out/target/product/dream/userdata.img

the system should always be capable of booting from an empty /data partition. Note that the boot will be longer in

this case because a lot of caches must be recreated (the same applies to the emulator with -wipe-data)

[Russell]

> . build/ensetup.sh    -- setup environment
> lunch dream-eng      -- setup Dream build + engineering options (larger but
> better for debugging)
> make -j8                 -- rebuild on a Quad-core machine

...how do i even get "lunch dream-eng" working? I have the latest
source from git which builds android 1.5 but i can only do lunch 1,
dream-eng isn't found?

Do i have to follow these steps to install the extra packages?

http://source.android.com/documentation/building-for-dream

Currently i can only build "generic" and when i install that on the
phone with your fastboot commands it has no GSM signal etc.
Thanks
Russell

[David Turner]

Ah sorry, dream-eng is now deprecated, you should try generic-eng instead.

[joel]

Will there be a replacement for dream-eng then, since Russell is
saying generic doesn't support the full dream hardware apparently?

On Mar 11, 6:48 pm, David Turner <di...@android.com> wrote:
> Ah sorry, dream-eng is now deprecated, you should try generic-eng instead.
>

[joel]

Hmm although I am not using 'lunch', just the "Building For Dream"
instructions, I do seem to be doing an htc-dream eng build...

[Morgan Condon]

Greetings.

Regarding ramdisk.img:
I recently discovered that my mac has 21 copies of this ramdisk.img file averaging 150 kb each; is it safe to delete these?  (esp since I have no active android projects going on right now)

Thanks

[Poletto Enrico]

Hi, did you manage to import the files into the real phone? If yes, how did he do it?