Android x86?

[David Simmons]

Has anyone looked into what it would take to port Android to x86? I'm
interested in taking a crack at porting Android to an x86-based
embedded platform I work with. I'm going to download the source later
today and have a look. My main concern is that Dalvik may be tied to
special ARM optimizations...

David

[Srinath T V]

By porting to X86, do you mean running on smart devices like PDA and
others?

I was also looking at porting into some special hardware and add
specific applications on top of it. I assume that android does a
pretty good job of doing power management and would like to see how it
performs compared to other special OS.

Srinath

[Zach Hobbs]

I'd like to port it to x86 to have the dalvik virtual machine running directly
on my linux PC instead of having it run in qemu emulating the ARM arch.

Any idea where to get started with this? Obviously it's ok if most (all) of
the telephony features don't work...

--

Zach Hobbs
HelloAndroid.com
Android OS news, tutorials, downloads

[Jay Freeman (saurik)]

I believe the magic step two between "step one: download code" and "step
three: profit" is just "build code". It seems to already be ported quite
well to x86, and even has user-space reimplementations of kernel extensions
like ashmem ready to go. -J

--------------------------------------------------
From: "Zach Hobbs" <ho...@helloandroid.com>
Sent: Tuesday, October 21, 2008 2:10 PM
To: <android...@googlegroups.com>
Subject: [android-porting] Re: Android x86?

[Brian Swetland]

["Jay Freeman (saurik)" <sau...@saurik.com>]

>
> I believe the magic step two between "step one: download code" and "step
> three: profit" is just "build code". It seems to already be ported quite
> well to x86, and even has user-space reimplementations of kernel extensions
> like ashmem ready to go. -J

Be aware that the SIMULATOR target (where the system sorta builds a
single big linux app) is deprecated and has a lot of problems.

That said, it should be possible to get things running on x86. We've
had somebody in-house tinkering with an x86 native port but he's on
vacation this week, so I'm not sure what the state of that is.

Brian

[Jay Freeman (saurik)]

Fair enough. I got a lot of Dalvik compiling on x86 before starting on it
with my iPhone toolchain, and it at least /seemed/ complete ;P. I didn't
actually bother getting it to a runnable state or I might have noticed that
it actually wasn't. (I'm on 64-bit Debian and I didn't want to spend the
time installing 32-bit libcrypto so I could finish my -m32 build of it all.)

I had completely bypassed the build environment (I usually do so on my first
pass through so I can better isolate build environment challenges from code
challenges and also get a feel for how the codebase is organized). If it, in
fact, isn't already setup for this then other people may find that useful to
dig into things faster, so here is that script. I believe the only thing
between this and linking is having the native libcore parts compiled in
(which had enough random dependencies that I figured I'd bail before I ran
into 32-bit compatibility hell ;P, example: libcrypto).

-J

#!/bin/bash
set -e

libdex=(dalvik/libdex/*.c)
liblog=(system/core/liblog/logd_write.c)
libcutils=(system/core/libcutils/{ashmem-host,atomic,dlmalloc_stubs,mspace}.c)
bionic=(bionic/libc/bionic/dlmalloc.c)
vm=(dalvik/vm/{.,alloc,analysis,arch/generic,interp,jdwp,mterp,oo,reflect,test}/*.c)
vm[${#vm[@]}]=dalvik/vm/mterp/out/InterpC-desktop.c
libnativehelper=(dalvik/libnativehelper/*.c)
libcore=($(find dalvik/libcore -name '*.c'))

include=(-Idalvik -Iframeworks/base/include -Isystem/core/include -Iexternal/safe-iop/include
-Idalvik/libnativehelper/include/nativehelper -Idalvik/vm -Iexternal/icu4c/common
-Iexternal/icu4c/i18n)

define[${#define[@]}]=-include
gcc='gcc -m32'
define[${#define[@]}]=system/core/include/arch/linux-x86/AndroidConfig.h
define[${#define[@]}]=dalvik/vm/mterp/out/InterpAsm-desktop.S

${gcc} -o dalvikvm dalvik/dalvikvm/*.c "${libcutils[@]}"
"${libnativehelper[@]}" "${bionic[@]}" "${libdex[@]}" "${vm[@]}"
"${liblog[@]}" "${include[@]}" "${define[@]}" -lm -pthread -ldl -lz -lffi
${gcc} -o dexdump dalvik/dexdump/*.c "${liblog[@]}" "${libdex[@]}"
"${include[@]}" "${define[@]}" -lz

-J

--------------------------------------------------
From: "Brian Swetland" <swet...@google.com>
Sent: Tuesday, October 21, 2008 5:22 PM

To: <android...@googlegroups.com>
Subject: [android-porting] Re: Android x86?

>

[Joe Onorato]

The x86 port is on a different branch that we haven't released yet, that has a bunch of other experimental and future work.  What's out there right now is pretty close to what's on the G1.  

We'll have that out soon hopefully, but I don't know about the time frame for sure.  We'll probably let what's out there settle down before we try to do that integration.  It'll be a fair bit of work to get that branch synced up with what we released.

-joe

[fadden]

On Oct 21, 5:35 pm, "Jay Freeman \(saurik\)" <sau...@saurik.com>
wrote:

> Fair enough. I got a lot of Dalvik compiling on x86 before starting on it
> with my iPhone toolchain, and it at least /seemed/ complete ;P. I didn't
> actually bother getting it to a runnable state or I might have noticed that
> it actually wasn't. (I'm on 64-bit Debian and I didn't want to spend the
> time installing 32-bit libcrypto so I could finish my -m32 build of it all.)

The only part of Dalvik that isn't portable is the JNI call bridge
(see dalvik/vm/arch directory). We currently use libffi for that on
non-ARM platforms, which is a bit of a performance drag, but on most
non-ARM platforms you don't care as much. :-) I can confirm that it
runs well on x86, and once upon a time we had it running on PPC (which
is mostly interesting because it's big-endian).

The VM runtime has very few external dependencies. The core libraries
have a bit more reach. :-)

[kapare]

Nice

Can you give me clue or example of how to compile the dalvik for x86
or PPC.

simple command line

thx

[fadden]

On Oct 23, 9:52 am, kapare <kevyn.alexandre.p...@gmail.com> wrote:
> Can you give me clue or example of how to compile the dalvik for x86
> or PPC.

Start with:

. build/envsetup.sh
lunch 2

This configures you to build for the desktop, linking against glibc.
This mode is NOT recommended for anything but experimental use. It
may go away. Don't use it; forget you saw it. Thanks.

Build the world:

make

When that completes, you have a working dalvikm on your desktop
machine:

% dalvikvm
E/dalvikvm(19521): ERROR: must specify non-'.' bootclasspath
W/dalvikvm(19521): JNI_CreateJavaVM failed
Dalvik VM init failed (check log file)

To actually do something, you need to specify the bootstrap class path
and give it a place to put DEX data that it uncompresses from jar
files. You can do that with a script like this:

----- snip & save -----
#!/bin/sh

# base directory, at top of source tree; replace with absolute path
base=`pwd`

# configure root dir of interesting stuff
root=$base/out/debug/host/linux-x86/product/sim/system
export ANDROID_ROOT=$root

# configure bootclasspath
bootpath=$root/framework
export BOOTCLASSPATH=$bootpath/core.jar:$bootpath/ext.jar:$bootpath/
framework.jar:$bootpath/android.policy.jar:$bootpath/services.jar

# this is where we create the dalvik-cache directory; make sure it
exists
export ANDROID_DATA=/tmp/dalvik_$USER
mkdir -p $ANDROID_DATA/dalvik_cache

exec dalvikvm $@
-----

Of course, you can't just run this against javac output, since it's
not a Java VM. You have to run your class files through "dx":

% cat > Foo.java
class Foo { public static void main(String[] args) {
System.out.println("Hello, world");
} }
(ctrl-D)
% javac Foo.java
% dx --dex --output=foo.jar Foo.class
% ./rund -cp foo.jar Foo
Hello, world
I/dalvikvm(19564): DestroyJavaVM shutting VM down

(I really ought to get rid of that DestroyJavaVM line -- it's supposed
to be in the log file, but on the desktop the "log file" is stderr.)

Get some info about valid arguments like this:

% ./rund -help

This also shows what options the VM was configured with. The "lunch
2" build has all sorts of additional assertions and checks enabled,
which slows the VM down, but since this is just for experiments it
doesn't matter.

All of the above applies to x86 Linux. Anything else will likely
require a porting effort.

[Filipe Abrantes]

Sorry for the basic question, but what is the lunch command, I've
looked for it in the android tree and google it but was unable to find
any meaningful reference.

Thanks,
Filipe

> All of the above applies tox86Linux.  Anything else will likely
> require a porting effort.

[Filipe Abrantes]

Sorry, I just realised "lunch 2" are the arguments of the envsetup
script :~, nice :P

Cheers,

Filipe


On Oct 23, 11:26 pm, fadden <thefad...@gmail.com> wrote:

> All of the above applies tox86Linux.  Anything else will likely
> require a porting effort.

[Jim Ancona]

On Oct 23, 7:26 pm, fadden <thefad...@gmail.com> wrote:
> On Oct 23, 9:52 am, kapare <kevyn.alexandre.p...@gmail.com> wrote:
>
> > Can you give me clue or example of how to compile the dalvik for x86
> > or PPC.
>
> Start with:
>
>   .build/envsetup.sh
>   lunch 2
>

> This configures you tobuildfor the desktop, linking against glibc.

> This mode is NOT recommended for anything but experimental use.  It
> may go away.  Don't use it; forget you saw it.  Thanks.
>
> Buildthe world:
>
>   make

When I try this (on Ubuntu 8.04, 32 bit), I get a bunch of errors
similar to this:

out/debug/host/linux-x86/product/sim/obj/SHARED_LIBRARIES/
libmedia_intermediates/mediametadataretriever.o:/media/disk/jim/
projects/mydroid/external/skia/include/corecg/SkMath.h:180: more
undefined references to `Android_SkDebugf(char const*, int, char
const*, char const*, ...)' follow
collect2: ld returned 1 exit status
make: *** [out/debug/host/linux-x86/product/sim/obj/SHARED_LIBRARIES/
libmedia_intermediates/LINKED/libmedia.so] Error 1

I can fix them by adding

LOCAL_SHARED_LIBRARIES += libcorecg

to the relevant Android.mk files, but I'm curious if anyone else is
seeing this, or if this is a problem with my environment.

Thanks,

Jim

[freedom]

I ran into similar problem, too. And yes, something similar to
LOCAL_SHARED_LIBRARIES += libcorecg
can solve it.

[linp...@gmail.com]

I have complied the source code for x86 platform,and it seems that it
comlied successfully,but has problems in link libz.so.
the result shows as follow:
============================================
TARGET_PRODUCT=generic
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
========================================================================================
TARGET_PRODUCT=generic
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=release
TARGET_ARCH=x86
TARGET_OS=linux
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=TC3
============================================
target SharedLib: libz (out/host/linux-x86/product/generic/obj/
SHARED_LIBRARIES/libz_intermediates/LINKED/libz.so)
make: *** No rule to make target `build/core/prelink-linux-x86.map',
needed by `out/host/linux-x86/product/generic/symbols/system/lib/
libz.so'. Stop.target SharedLib: libz (out/host/linux-x86/product/
generic/obj/SHARED_LIBRARIES/libz_intermediates/LINKED/libz.so)
make: *** No rule to make target `build/core/prelink-linux-x86.map',
needed by `out/host/linux-x86/product/generic/symbols/system/lib/
libz.so'. Stop.




there is not "prelink-linux-x86.map" in "build/core/" actually but
just the "prelink-linux-x86.arm". Is the "prelink-linux-x86.map
"created automatically?
so any ideas?

[Filipe Abrantes]

same here...

Cheers,
Filipe

[dannie]

Got the same errors with LOCAL_SHARED_LIBRARIES,
fixed them and it seems all was compiled/linked successfully.

Ubuntu 8.04

============================================
TARGET_PRODUCT=sim
TARGET_SIMULATOR=true
TARGET_BUILD_TYPE=debug

[dannie]

I'm getting the following error when trying to run dalvik:

~/temp/and$ ./rund -cp foo.jar Foo
E/dalvikvm( 313): Can't open dex cache '/tmp/dalvik_dannie/dalvik-
cache/home@dannie@temp@and@system@framework@core...@classes.dex': No
such file or directory
I/dalvikvm( 313): Unable to open or create cache for /home/dannie/
temp/and/system/framework/core.jar
W/dalvikvm( 313): JNI_CreateJavaVM failed

Dalvik VM init failed (check log file)

But... why? =)

[Filipe Abrantes]

Hi, its a small typo on the rund script, just replace

mkdir -p $ANDROID_DATA/dalvik_cache

with

mkdir -p $ANDROID_DATA/dalvik-cache

and it will (hopefully :P) run

Cheers,
Filipe

On Oct 30, 11:28 am, dannie <dannie....@gmail.com> wrote:
> I'm getting the following error when trying to run dalvik:
>
> ~/temp/and$ ./rund -cp foo.jar Foo
> E/dalvikvm(  313): Can't open dex cache '/tmp/dalvik_dannie/dalvik-

> cache/home@dannie@temp@and@system@framew...@core.jar@classes.dex': No

[dannie]

What's a weird mistake! =)

./rund -cp foo.jar Foo
Hello, world

I/dalvikvm(26218): DestroyJavaVM shutting VM down

So... It's working.

[freedom]

a quick fix to the problem is "choosetype release" after
"lunch 2" because in release mode "SkDebugf()" is an
empty function instead of "Android_SkDebugf()"

On Oct 30, 9:28 am, Jim Ancona <j...@anconafamily.com> wrote:

[Filipe Abrantes]

Hi all,

The target simulator compilation method for x86 works and we are able
to run dalvik. However I am trying to compile android with all its
components natively for x86. To do so I set up the repo thing as
usually and then run make (without any "lunch") as

make TARGET_ARCH=x86

it goes through quite a few modules but eventually it complains about
the lack of rule to make emulator. I dig through a few files in build/
(core and others) to try to understand how I could change this but I
was not successfull. The output error is:

Install: out/host/linux-x86/bin/dexlist
host Prebuilt: dexpreopt (out/host/linux-x86/obj/EXECUTABLES/
dexpreopt_intermediates/dexpreopt.py)
make: *** No rule to make target `out/host/linux-x86/bin/emulator',
needed by `out/host/linux-x86/bin/dexpreopt.py'. Stop.

Any help is much appreciated, Cheers,
Filipe

[freedom]

Try
make TARGET_ARCH=x86 TARGET_BUILD_TYPE=release TARGET_PRODUCT=sim

[Filipe Abrantes]

Ok, but that will compile for the target 'SIMULATOR' right? My idea
was compile everything for an x86 device. I don't fully understand the
differences between the simulator target and the other ones... for
instance I understand that on the simulator target dalvik is compiled
against the 'standard' glibc but what else is different?

Cheers,
Filipe

[Brian Swetland]

[Filipe Abrantes <filipe....@gmail.com>]

>
> Ok, but that will compile for the target 'SIMULATOR' right? My idea
> was compile everything for an x86 device. I don't fully understand the
> differences between the simulator target and the other ones... for
> instance I understand that on the simulator target dalvik is compiled
> against the 'standard' glibc but what else is different?

The SIMULATOR target tries to build the entire system more like an
application. Things don't really run in multiple processes. A lot of
things don't work the way they would on a real devices. It still exists
as a debugging aid (you can run it all under valgrind which is kinda
handy at times) but it's deprecated and will be going away (as soon as
we get valgrind type functionality with the emulator or on-device). It
is the source of a lot of cruft in the build.

[Filipe Abrantes]

Thanks for the clarification Brian. The big app you mention is the
'dalvikvm' binary? Could you point us how we could get, for instance,
the android home app running with this dalvikvm binary? Is it even
possible to do this... I mean we were able to run a simple hello world
java app, but I could not get any of the Android jars (e.g.
out/target/common/obj/APPS/Home_intermediaries/classes.jar) running.

Cheers,
Filipe

Could you help us understand what is required to get, for instance, the
home app running on

[DYChen]

Brian,

You mentioned on Oct 21 that Google has done some native x86 port of
Android. Do you know when the code related to the native x86 port will
be released to the Android Open Source Project? We are interested in
getting Android to run on various x86-based devices and are willing to
contiribute toward the native x86 port effort. But it will be better
to base it on top of the native x86 port that Google has done.

Thanks,
Dong-Yuan

[Brian Swetland]

[DYChen <dong-yu...@intel.com>]

The engineer responsible for this project has been out of the office for
a couple weeks and is travelling this week. He's working with our team
to get his patches into the open source tree, but I think we're still a
couple weeks away from completion there. We know people are excited
about building android for x86 targets and will try to get this code
cleaned up and submitted soon.

Brian

[DYChen]

On Nov 7, 6:42 pm, Brian Swetland <swetl...@google.com> wrote:
>
> The engineer responsible for this project has been out of the office for
> a couple weeks and is travelling this week.  He's working with our team
> to get his patches into the open source tree, but I think we're still a
> couple weeks away from completion there.  We know people are excited
> about building android for x86 targets and will try to get this code
> cleaned up and submitted soon.

Brian,

Thanks for the update. I look forward to the release of x86 patches
that will enable us to run Android natively on x86 devices or PC.

Do you know how the project repositories will be structured to
accommodate the support of various x86 devices or targets? Are we
going to see different branches for x86 port? Are we expect to see
macros (such as #ifdef X86) guarding x86 related code in the source?
I'm looking for some guidelines on how x86 related code should be
integrated with the existing Android source. I haven't seen any
guideline regarding coding style or repository structures for hosting
device or architecture specific code yet. Maybe I haven't looked hard
enough. Any pointer is greatly appreciated.

Thanks,
Dong-Yuan

[David Turner]

Just to make it clear, the x86 Android port, at that point, requires running an Android kernel on a x86 device with flash storage.
This is very different from running Dalvik under Windows or a pre-existing Linux installation (though with time these things
will be possible to)

[Gergely Kis]

Hello,

Why is flash storage necessary? We were able to run Android over NFS,
and others have used ext2 or ext3. So there should be no direct
requirement for using a flash device specific filesystem like yaffs.
As far as I know the only specific requirement is that read-write mmap
has to be possible.

Are there other dependencies on flash storage?

Best Regards,
Gergely

On Tue, Nov 11, 2008 at 10:28 AM, David Turner <di...@android.com> wrote:
> Just to make it clear, the x86 Android port, at that point, requires running
> an Android kernel on a x86 device with flash storage.
> This is very different from running Dalvik under Windows or a pre-existing
> Linux installation (though with time these things
> will be possible to)
>
> On Sun, Nov 9, 2008 at 10:01 AM, DYChen <dong-yu...@intel.com> wrote:

[...]

[David Turner]

I just mean that it's the only option that has really been tested in real life :-)

[markgross]

We have been looking into this and we are in the process of internal
legal review and will be starting an AndroidOnIA project within the
context of the Android open source project soon.

We have a few interesting targets we are working on, but initially we
hope to get a KVM (or your VTx enabled VMM of choice) guest image
build working for people to play with,and then start pushing out
targets for real hardware.

--mgross

On Oct 21, 8:44 am, David Simmons <simm...@davidsimmons.com> wrote:
> Has anyone looked into what it would take to port Android to x86? I'm
> interested in taking a crack at porting Android to an x86-based
> embedded platform I work with. I'm going to download the source later
> today and have a look. My main concern is that Dalvik may be tied to
> special ARM optimizations...
>
> David

[Gang lee]

Hi all:

Although I can compile with the command line:
make -j2 TARGET_ARCH=x86 TARGET_PRODUCT=generic
TARGET_SIMULATOR=true TARGET_BUILD_TYPE=release TARGET_OS=linux
LOCAL_PRELINK_MODULE=false

but I found lot of modules cannot be compiled with
"TARGET_SIMULATOR=true", if set false,the bionic(libc) met some files
(.h files) missing and compile failed.
Has anyone compiled the bionic successful?

Another question, Does any one knows more detail information about the
official x86 porting? for example:
Does the x86 porting support OpenGL?
Does the x86 porting still use openCore as the Media Framework? and
the openCore can be replaced by others(just like Hilex or GStreamer)?

[David Turner]

Do not use TARGET_SIMULATOR=true, this flag should only be set when building the Android simulator,
which doesn't require all system libraries and runs the Android "system" into a single process on the host
machine.

that's why you have problems when building certain libraries (e.g. the simulator uses the host's C library, not Bionic)

the x86 port only uses Android's own software OpenGL renderer. There is no support for hardware-accelerated graphics
yet (and it's not like there is any kind of standard API for that on Linux). OpenCore is supposed to be portable, so I
assume it runs (but I may be mistaken)

you can't easily replace OpenCore with something else, unless you modify all the framework code that depends on it.
(this has never been tested internally)

[Gang lee]

Hi David,

Think you for your answer.

I'm sorry for my copy&paste mistake.
I can compile with TARGET_SIMULATOR=true without any problem.
but when set "TARGET_SIMULATOR=false" in compile command, error below
happend

make: *** No rule to make target `out/host/linux-x86/bin/emulator',
needed by `out/host/linux-x86/bin/dexpreopt.py'. Stop.

Then I want to compile the bionic first.I did as follow.
1. Modify the Android.mk in mydroid/bionic to compile bionic in
simulator target
2. Compile all again with TARGET_SIMULATOR=true
the output as follow:
-------------------output------------------------
target thumb C: linker <= bionic/linker/linker.c
target thumb C: linker <= bionic/linker/dlfcn.c
bionic/linker/linker.c:15:25: error: sys/atomics.h: No such file or
directory
bionic/linker/linker.c:16:21: error: sys/tls.h: No such file or
directory
In file included from bionic/linker/dlfcn.c:18:
bionic/linker/linker.h:20: error: expected specifier-qualifier-list
before 'uintptr_t'
In file included from bionic/linker/linker.c:18:
bionic/linker/linker.h:20: error: expected specifier-qualifier-list
before 'uintptr_t'
bionic/linker/linker.h:50: error: expected specifier-qualifier-list
before 'uintptr_t'
bionic/linker/linker.h:50: error: expected specifier-qualifier-list
before 'uintptr_t'
---------------copy end(firest several lines)------------------

How can I compile bionic and other modules(init etc.)??

On 11月14日, 下午7时24分, "David Turner" <di...@android.com> wrote:
> Do not use TARGET_SIMULATOR=true, this flag should only be set when building
> the Android simulator,
> which doesn't require all system libraries and runs the Android "system"
> into a single process on the host
> machine.
>
> that's why you have problems when building certain libraries (e.g. the
> simulator uses the host's C library, not Bionic)
>
> the x86 port only uses Android's own software OpenGL renderer. There is no
> support for hardware-accelerated graphics
> yet (and it's not like there is any kind of standard API for that on Linux).
> OpenCore is supposed to be portable, so I
> assume it runs (but I may be mistaken)
>
> you can't easily replace OpenCore with something else, unless you modify all
> the framework code that depends on it.
> (this has never been tested internally)
>

[Gang lee]

Hi David

A few additional information.

when I compiled whit TARGET_SIMULATOR=false, the output said "find:
prebuilt/android-x86: No such file or directory"
the make try to find prebuilt/android-x86 directory, and there is no
such directory,only have linux-x86 directory.
In the mydroid/build/core/envsetup.mk
--------------------------------
envsetup.mk-----------------------------
ifeq ($(TARGET_SIMULATOR),true)
TARGET_PREBUILT_TAG := $(TARGET_OS)-$(TARGET_ARCH)
else
TARGET_PREBUILT_TAG := android-$(TARGET_ARCH)
endif
--------------------------------copy end-----------------------------
Say in other words,If I set TARGET_SIMULATOR=false, I cannot use the
prebuild content??

On 11月14日, 下午7时24分, "David Turner" <di...@android.com> wrote:

> Do not use TARGET_SIMULATOR=true, this flag should only be set when building
> the Android simulator,
> which doesn't require all system libraries and runs the Android "system"
> into a single process on the host
> machine.
>
> that's why you have problems when building certain libraries (e.g. the
> simulator uses the host's C library, not Bionic)
>
> the x86 port only uses Android's own software OpenGL renderer. There is no
> support for hardware-accelerated graphics
> yet (and it's not like there is any kind of standard API for that on Linux).
> OpenCore is supposed to be portable, so I
> assume it runs (but I may be mistaken)
>
> you can't easily replace OpenCore with something else, unless you modify all
> the framework code that depends on it.
> (this has never been tested internally)
>

[Filipe Abrantes]

This would be very interesting. Any word on timing?

Cheers,
Filipe

[neo]

Good afternoon everyone,
there is a problem during my Android kernel compiling .
I followed the guideline which is
https://sites.google.com/a/android.com/opensource/download
and searched google for the answer, but still it cannot be solved.

===
Cannot locate File/ Basename.pm in @INC
( @INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/
share
/perl/5.8.8 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/
5.8 /usr/local
/lib/site_perl. )
at external/webkit/JavaScriptCore/pcre/dftables line 47

BEGIN failed--compilation aborted at external/webkit/JavaScriptCore/
pcre/dftables line 47

make" ***[out/target/product/generic/obj/STATIC_LIBRARIES/
libkjs_intermediates/chartables.c]Error2
===
Can anyone give me some advice? I'll appreciate u very much.

thanks for reading

[Lucky-dog]

My ubuntu is 8.10. I try the tips to compile android for x86. But it
seem envsetup.sh does not work. Would you like to help me? Thank you
very much. The log is as below.
thomast@ubuntu:~/mydroid/build$ echo $SHELL
/bin/bash
thomast@ubuntu:~/mydroid/build$ bash --version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
thomast@ubuntu:~/mydroid/build$ ./envsetup.sh lunch 2
thomast@ubuntu:~/mydroid/build$ ./envsetup.sh help
thomast@ubu