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. How to add a new device?

I want to add a new device. It's an alpha-numeric (16X2) monochrome
LCD. I have finished the driver of kernel, and I can see the device
from console. The device's name is "/dev/monolcd".
Now I don't know how to control it from application. Can anyone tell
me how to do it?


2. VBO on Motorola CLIQ

I've been testing our games on Motorola CLIQ (aka MB200) using
DeviceAnywhere. While the OpenGL driver indicates support for VBO
(GL_OES_vertex_buffer_object GL_ARB_vertex_buffer_object) calling any
VBO function yields "called unimplemented OpenGL ES API". The weird
thing is that sometimes it works for no apparent reason with no
changes made to app besides debug prints.

Is anyone using VBO on CLIQ succesfully?



3. How to detect if a Bluetooth A2DP headset is connected

4. setResult() for AppWidget

5. IP broadcast on emulator

6. Source Code required for Android App

7. Updating one view also causes another view to update