Android Simulator Environment

[Augustin.CL]

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.

B.R.
Augustin.

[Jamai@work]

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

JZ

[fadden]

On Apr 29, 2:16 am, "Augustin.CL" <iamaugus...@gmail.com> 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.