On Apr 29, 2:16 am, "Augustin.CL" <[email protected]> wrote: > Recently, I set out to compile android on X86. I read lots > of discussions on mailing list. I found that someone gave a guide to > compile simulator and introduce how to write a java program to print > out "Hello World" by Dalvikvm. Could I run a android application > (include activities,services,etc )through simulator? If not, what does > simulator do?
In the beginning, there was a technology demo. It was written in C and Javascript, and used SDL for framebuffer and event management. Great for demos, not so great for actually building something useful. We decided to switch to the Java language, and wanted a somewhat more rigorous development environment. Standard Operating Procedure for consumer electronics work is to have a terrible shortage of actual hardware, especially in the early days, so you really want to have some sort of desktop simulator that allows most team members to get work done even when they don't have physical devices. You really don't want to code everything twice, though, so you construct your software in a way that allows maximum code sharing between the real and virtual devices. The sim had a front-end that dealt with the graphics and event input, and we ran that in its own process to get a clean separation. The entire Android experience ran in another process (no IPC yet). We expected development in Linux, Mac OS X, and Windows, so we did the interface with wxWidgets. The original simulator was a bit nastier than the current one, because it was attempting to support the process model on both Linux and Windows; you can see bits and pieces of the original porting work in the "utils" lib. As time went on we began developing other bits and pieces, like "bionic" libc and the binder IPC driver. This left us running code with two different libc implementations, and the Mac OS X developers were stuck with single-process mode since the binder driver wasn't ported to work there. Because it was running natively on the desktop, which has a far more powerful CPU and more RAM than a device, performance work was meaningless. Once we got qemu running, the simulator became largely unused overnight. However, there's one thing that we just couldn't live without: valgrind. When you're pulling in large quantities of native code, it's really handy to have a good bug finder. We declared that the simulator would be Linux-only, and went through and rearranged some of the plumbing to get rid of some of the "#ifdef HAVE_ANDROID_OS" code that was piling up. This is when the fun bits in development/ simulator/wrapsim went in. Keeping the simulator alive has had some positive consequences. Notably, it prevented anyone from making ARM-specific assumptions, which made the x86 port easier. Having a build that uses glibc means our code is easier to port to GNU/Linux systems, and anybody who really wants to use glibc will have less work to do. However, there's a difference between the "simulator" and simply having a desktop build. I use the desktop build all the time for VM development, but I rarely if ever run the actual simulator. Due to bit rot it tends to be non-functional much of the time, usually because of environmental differences (everything runs in one process, don't have multiple user IDs), but occasionally because of race conditions. Even with a ton of assertions and other debugging enabled, the simulator runs many times faster than the emulator or a real device. So... in theory you can use the simulator to have the full Android experience. In practice, we don't make regular efforts to keep it running, so it will likely come up most of the way and then fail. If you're really interested in learning how the Android framework works, debugging the simulator startup will certainly provide an education. :-) At some point the simulator will likely disappear, though I expect the desktop build will survive. --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
