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.

B.R.
Augustin.
--~--~---------~--~----~------------~-------~--~----~

-~----------~----~----~----~------~----~------~--~---



Android Simulator Environment

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


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

JZ



--~--~---------~--~----~------------~-------~--~----~

-~----------~----~----~----~------~----~------~--~---


Sponsored Links


Android Simulator Environment

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


 n Apr 29, 2:16am, "Augustin.CL" <iamaugus...@gmail.com> 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. app not working ,need help

hi , i have two programmes ,a TextSpeaker in which i start a TTS
engine and a SmsReceiver pgm where i use BroadcastReceiver to inform
user of any incoming message . Both these pgms worked well when run
separately ,but when i kept them in the same project so as to make the
incoming msg in voice form  i am getting runtime error .

here are the programmes :
Receiver pgm http://pastebin.com/KBAa04zL
TextSpeaker pgm   http://pastebin.com/G5yctFQa

-- 

2. Pasar Malem apa tidak buka

Mulai dari tadi malem saya ga bisa masuk ke pasar malem... kenapa ya ?
apakah problemnya di koneksi inet saya ya ?
soalnya web nya saya buka lewat pc juga ga bisa neh :(

-- 
"Indonesian Android Community [id-android]" 

3. Fwd: OnSharedPreferenceChangeListener never receives callback

4. Youtube Streaming not working on Andriod 2.1

5. How to add application settings in android device

6. How to add application settings in android device

7. ROM 1.7 untuk Acer Liquid