On Sun, Feb 22, 2009 at 6:04 AM, MBethDev <[email protected]> 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) MBeth > > On Feb 21, 12:27 am, David Turner <[email protected]> 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 <[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- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
