Android Simulator Environment

by Augustin.CL » Wed, 29 Apr 2009 17:16:25 GMT

Sponsored Links
 Dear All,

          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?

           Could anyone clarify this for me?

Thanks a lot.



Android Simulator Environment

by ja...@work » Wed, 29 Apr 2009 18:22:11 GMT

 I just thought the same... what does the simulator do???




Sponsored Links

Android Simulator Environment

by fadden » Thu, 30 Apr 2009 02:27:38 GMT

 n Apr 29, 2:16am, "Augustin.CL" <> wrote:

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 intere

Other Threads

1. Need help using hat to track down memory usage


While perusing the source code, came across a shell function that defines called "runhat". Judging by the parameters, etc.,  
to this function, it allows one to get a heap-dump for a given  
application. This dump can then be analyzed by the tools "hat" and  

Has anyone had any luck running these tools? I tried earlier today and  
consistently get an error message

Started HTTP server on port 7000
Reading from /tmp/t.hat... Version string not recognized at byte 17
        at hat.parser.HprofReader.readVersionHeader(
        at hat.parser.Reader.readFile(
        at hat.Main.main(

I have tried jhat (built into Java SE 6.0) as well as hat (downloaded  
from Both versions get the same error.

Can anyone help?



2. Ultimate Android Calendar - AnCal available for download and testing !


After year of developing, you can download first free public version
of my Android application:

However, please note, that I do not own G1 phone, and AnCal has not
been yet tested on a real device.
There can be many bugs and other problems, please be patient, I'll try
fix bugs as soon, as possible.

I hope, you will like this utility.

Write suggestions, bugfix requests or questions here or to my private

Best regards.
Piotr Zagawa


3. Warning on Ignoring InnerClasses attribute with dex

4. Getting a G1...

5. apache httpclient usage in 1.0 r2 release

6. connection in sqlite

7. The G1 (RC30) K-9 eMail client