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.
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 <mbeth...@gmail.com> 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.
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
> 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 <mbeth...@gmail.com> 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.
On Sun, Feb 22, 2009 at 6:04 AM, MBethDev <mbeth...@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)
> 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
> > 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 <mbeth...@gmail.com> 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.
> . 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?
On Wed, Mar 11, 2009 at 10:47 PM, Russell <rjcolling...@gmail.com> wrote:
> > . 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?
> Ah sorry, dream-eng is now deprecated, you should try generic-eng instead.
> On Wed, Mar 11, 2009 at 10:47 PM, Russell <rjcolling...@gmail.com> wrote:
> > > . 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?
> > 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
> 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.
> > On Wed, Mar 11, 2009 at 10:47 PM, Russell <rjcolling...@gmail.com> wrote:
> > > > . 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?
> > > 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
