Test drive

Ethernet support for Eclair

2009-12-26T15:51:00.000-08:00

I have created two patches for Ethernet support in Eclair. I don't want to check them in until I finish a complete test. For the early access, you can download it from the download section in android-x86.org

BTW--Chih-wei has also posted a nice video on youtube to demonstrate a really fast fastboot of Android-x86 on EeePC 901. You can find the video from http://www.youtube.com/watch?v=QeSg7S

Yi

release of android-x86 20091113 test build

2009-11-14T18:16:00.001-08:00

The Android-x86 project is glad to announce a new test build
20091113 for public testing. A live cd ISO and USB image are
available from our site:

http://www.android-x86.org/download
http://code.google.com/p/android-x86/downloads/list

Features:
Build 20091113 is Android 1.6 (Donut) based and it is a release candidate for android-x86 1.6 stable release.
In addition to the features available in previous release, the new build contains

* Hardware OpenGL support from olv in 0xlab.
* Fn key support for EeePC platforms.
* External USB bluetooth support.
* NDK for X86 platforms is supported (based on the original work from guillaume.etievent@laposte.net)
* new touch features to simulate home/menu/back keys to support touch only device.
* Improvement on the keyboard support. User can use ctrl+c directly from terminal simulator now.
* A lots of bug fixes.

Released Files:
* Live CD iso: android-x86-20091113.iso

sha1sum: dec0b99a6fe1e33e05b665e82f3020f612eb14bf

* Live USB image: android-x86-20091113_usb.img.gz

sha1sum: ce040ced2da92c278c7df2527b5f3498a68afbfa

Source code:
The source code is available in our git server:

$ repo init -u git://git.android-x86.org/android-x86/platform/manifest.git
$ repo sync

Test reports (success or fail) are welcome.
Please send the reports to the Android-x86 discussion group.
http://groups.google.com/group/android-x86

compile openssl for mingw

2009-10-08T09:49:00.000-07:00

I was googling a correct step to build openssl with mingw. I followed different posts from different people, none of them give me anything good. After a whole afternoon of trying and failing, eventually, I got it right with following steps:

1. install cygwin on my PC. To avoid too much trying and failing, I have installed the full cygwin. Storage space is cheap but time is very expensive.

2. install mingw

3. download openssl from openssl.org. I used 0.9.8k

4. untar/unzip 0.9.8k package to cygwin how directory

5. start Cygwin xterm (ya, Cygwin not msys)

6. in the xterm, go to openssl-0.9.8k directory that you just unpacked

7. ./Configure mingw

8. make

The steps above create static library that can be used with mingw. To create the dll, you need to do:

$ echo EXPORTS > libcrypto.def

$ nm libcrypto.a | grep ' T _' | sed 's,^.* T _,,' >> libcrypto.def

$ dllwrap -o libcrypto.dll --def libcrypto.def libcrypto.a -lws2_32 -lgdi32

$ echo EXPORTS > libssl.def

$ nm libssl.a | grep 'T _' | sed 's,^.* T _,,' >> libssl.def

$ dllwrap -o libssl.dll --def libssl.def libssl.a libcrypto.dll

After this, you can copy the *.a to /mingw/lib and *.dll to /ming/bin

The wifi problem has been fixed

2009-09-12T21:52:00.001-07:00

Recntly, people reported issues with wifi. The bug really has nothing to do with the wifi. It is a memory corruption issue inside the system property manager. Long ago, I changed the size of system property name to support user configure-able battery sysfs path. This change will cause the size of shared memory for the system properties to increase. But the original code of shared memory creation uses a hard coded size and I was not aware of that. When the amonut of the total used system property entries increased to certain level, segfault will happen since system property entry may have pointed to a wrong address. After adjusted the code to create the share memory, it seems that the problem goes away.

If you are still seeing the issue, please report it in the discussion group.

Thanks

What is next

2009-09-03T21:47:00.000-07:00

Now, we have a realtivly stable system. Here are some items on my to do list:

1. enable vold to support external stroage by using fuzzy matching

2.In Android, by default, mkdir set the new directory permission to 0700. When install an new apk from web ui, the download provider tries to create a new directory called download in /sdcard. On G1 phone, the external storage is using vfat partition. And it does not enforce permission. So we can download and install the apk without any problem. But with android-x86, the external storage can use either ext2, ext3 or vfat, with the unix paritions, the permission will be enforced. So the apk install will fail. I may need to add new code the fix the permission.

3. hardware cursor, this item in my to do list for a very long time already.

The Android Etherent State Tracker Cont.

2009-08-25T20:27:00.001-07:00

Ok, I have committed the first release of the etherent state tracker for the Android. You can check out code from git.android-x86.org by using branch name eth-nm-dev-br. It is an alpha release. Please report the issues to the android-x86 group

Etherent state tracker cont.

2009-08-24T09:49:00.000-07:00

Slow.... the build is so slow, it eats up my 50% of time.

I'm getting there. I still need to clean up the conntectivityservice. This class does now know anything other than wifi and mobile. I need to add etherent into it. But before that I will try out the basic functionality and release a test path .

Add state tracker for etherent devices

2009-08-16T22:46:00.001-07:00

Android has state tracker (the connection management) for both mobile connections and wifi connections. But it does not support ethernet devices.
This is not an issue for a phone , but it causes following issues with netbook:
1. you can not manage your ethernet device from UI at all
2. With current way of enabling ethernet device (netcfg eth0 dhcp). If you unplug/plug cable, you will not have your dhcp ip address reset
3. ethernet device can not report connectivity changes correctly

Now, I'm working on the ethernet state tracker support for Android-x86. This blog thread is created to track this work.

How to access a C native service from Java side in Android

2009-06-06T23:53:00.000-07:00

I have mentioned how to add a native service by C. Now, it is the time to discuss about the client implementation. A client, in this document is a activity. It can talk to the native service to instruct the native service to do something for it.
It seems that there has no way to do this with a standard method supported by Android SDK. So I went to another route. I built a platform library. The platform library talks to the servicemanager.java to access the binder hence the native service. The code is very simple. To find out how to build and use a platform library, you can check out the android source code and take a look at the README.txt in the directory development/samples/PlatformLibrary

package com.servicelib.mybinder;

import android.util.Config;
import android.util.Log;
import android.os.ServiceManager;
import android.os.Binder;
import android.os.IBinder;
import android.os.Parcel;
import android.os.RemoteException;

public final class MyBinderLibrary {

private static IBinder mServiceManager = null;

public MyBinderLibrary() {

}

public static IBinder AttachService(String name) {
if (mServiceManager == null) {
mServiceManager = ServiceManager.getService(name);
}

return mServiceManager;
}

public static int SendKillSignal() throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
int result;
try{
data.writeInterfaceToken(mServiceManager.getInterfaceDescriptor());
mServiceManager.transact(TRANSACTION_sendKill,data,reply,0);
reply.readException();
result = reply.readInt();
}
finally{
reply.recycle();
data.recycle();
}

return result;
}
static final int TRANSACTION_sendKill = (IBinder.FIRST_CALL_TRANSACTION+0);
}

So, in your activity, call the methods in this class directly. So that you can talk to the native service. You need to make sure the name of the service is correct.

connect G1 phone to adb on Ubuntu

2009-05-29T09:36:00.001-07:00

You can find very detailed instructions on android page. But they missed one thing, that is adb needs to be run with root permission. So after you setup everything, do:
adb kill-server
sudo adb devices

The mouse cursor issue

2009-05-28T22:50:00.000-07:00

I did the mouse cursor support for X86 platforms. As matter fact, the same change should be able to run anyway.

But when I try to drag the screen to switch to next screen, I see the screen keeps flicking. It looks like a bug. In order to debug this problem, I wrote a small application to just draw lines on the screen. When I start to draw, I can see the lines keep jumping back to position 0,0 during the mouse cursor movement . It seems that the mouse cursor keeps sending out wrong mouse position.
After some debugging, I found out that it is cause by the batching mode of mouse event. Current mouse cursor tries to simulate the touch events, in order to do that, I have to convert the rel_x/y to abs_x/y and this conversion was never done for batched events. Because of this, both rel_x/y and abs_x/y are sent with touch events.
I have published the patch to
http://code.google.com/p/patch-hosting-for-android-x86-support/downloads/list

How to write Android native service by C contntinue

2009-05-22T22:44:00.000-07:00

Here is some thing I did; first, I copied biner.c to my private directory and used it as a library to access kernel binder driver. And then, I wrote my service to use the functions in binder.c to talk to service manager.
In order to talk with service manager, we need following things:
1. an unique id for the service we are going to build. It is a string16
2. add permission for our service to service manager.

For the point 1, I create an uint16 array like
uint16_t svcmgr_id16[] = {
'B','i','n','d','e','r','.','T','e','s','t','.','I','B','i','n',
'd','e','r','t','e','s','t'
};

for the point 2, I'm kind of lazy, I add a new item to the allowd[] in servicemanager. It looks like this:
{10001, "Binder.Test.IBindertest"}

Ok, lets get something real, we need to do following steps to make everything to work:
1. connect to the binder by calling binder_open function. The binder_open function creates a shared memory with /dev/binder. I copied service manager code to create a 128K shared memory.
2.create an io block through bio_init function to talk with service manager through binder. You need to provide a buff to bio_init. I use an integer array with size of 128
3. fill in the target (servicemanager) and source(Binder.Test.IBindertest) by calling bio_put_string16_x
4. call binder_call with command SVC_MGR_ADD_SERVICE. It is a blocking call. You need to provide a binder_io object for the result.
5. if binder_call returns 0, call binder_loop with a message handler callback function to process messages sent from service client.

The message processing callback function:
The prototype of the message processing callback functions is:
static int binder_handler(struct binder_state *bs,
struct binder_txn *txn,
struct binder_io *msg,
struct binder_io *reply)

In the callback function, we at least need to handle INTERFACE_TRANSACTION so that our service client can find our service.
switch(txn->code) {
case INTERFACE_TRANSACTION:
bio_put_string16(reply,svcmgr_id16);
break;
case :
default:
error handling.

How to write Android native service by C

2009-05-18T22:19:00.000-07:00

It is not as hard as I thought before I start. When I look into the frameworks/base/cmds/servicemanager, I realized that it should be an easy job. So I decide to give it a try. I will list what I do after I complete it.

How to build and use a shared libraries in Android

2009-05-12T16:10:00.000-07:00

Actually, it is very simple to build and use your own shared library,

For the shared library, you need to create an Android.mk like this:

  LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

  LOCAL_SRC_FILES := hello.c

  LOCAL_CFLAGS :=

  LOCAL_C_INCLUDES :=

  LOCAL_SHARED_LIBRARIES := libc        <=== may be not required

  LOCAL_MODULE := libhello

  include $(BUILD_SHARED_LIBRARY)

For the executable that needs use this shared library, the Android.mk needs to be written as :

  LOCAL_PATH:= $(call my-dir)

  include $(CLEAR_VARS)

  LOCAL_SRC_FILES := main.c

  LOCAL_SHARED_LIBRARIES := libc libhello

  LOCAL_MODULE := myprog          <=== the name of final executable

  include $(BUILD_EXECUTABLE)

Besides makefile changes, we also need to change build/core/prelink-linux-arm.map. Android does prelink (a modified version), all the memory location of DSO are predefined. In order to build a shared library for Android, you need to define the address and size for the memory used by your DSO (before you start to build anything). For current example, I have added following lines at the end of .map file.

  libhello.so            0x9A100000

  The C code I'm using to build this example is
main.c

  #include "myprog.h"

  int main(void)
{
    hello("World!");
    return 0;
}

  Hello.c
#include

  void hello(const char* name)
{
    printf("Hello %s!\n", name);
}

Android Suspend and resume (the wakelock problem)

2009-05-09T20:55:00.000-07:00

I enabled wakelock in my Android kernel today, after the wakelock is enabled on my PC, my machine failed to wake up. It seems that the machine gets back to suspend right after it is waken up.
I spent two hours to read the wakelock code and try to find out the reason for the problem. It seems that the wakelock.c checks a flag called entry_event_num during the machine resume process. The value of entry_event_num is saved before the machine goes into sleep, and wakelock checks it during the machine resume. If the value of entry_event_num did not changed since machine went to sleep, then wakelock will put the machine back to sleep again.
It looks like that the entry_event_num flag is used to verify whether the machnie is waken up from an expected event. If it is not, then machine will continue to sleep. To me this is more like a hack for a hardware bug.
So I hacked it to make my PC to sleep well and wake up on time :-). Here is the code I have changed:
diff --git a/kernel/power/wakelock.c b/kernel/power/wakelock.c
index 7833d28..175f8a3 100644
--- a/kernel/power/wakelock.c
+++ b/kernel/power/wakelock.c
@@ -292,11 +292,13 @@ static void suspend(struct work_struct *work)
tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
}
+#if 0
if (current_event_num == entry_event_num) {
if (debug_mask & DEBUG_SUSPEND)
pr_info("suspend: pm_suspend returned with no event\n");
wake_lock_timeout(&unknown_wakeup, HZ / 2);
}
+#endif
}
static DECLARE_WORK(suspend_work, suspend);

Actually, the wakelock is really not a good idea. From my current understanding, if one of the application hold a wakelock without timeout and dead, the machine may not be able to go to sleep forever until you reboot your machine.

Android on X86 Battery Service problem

2009-05-08T22:03:00.000-07:00

Recently, I got this EeePC netbook, beside accessing e-mail and web, I leave it on my desk for most of the time. One day, I saw this web site which talks about running Android on EeePC 701, so I decided to give it a try. Normally I like to record steps and findings when I try something, so that's wh I created this blog to record my experience on Android.

Here you go with my first blog...

When running Android Eee_701 build on a real machine, the battery service will not show the correct battery status on the status bar. Depending on what your battery is, you may get a warning says battery level lower than 15% or simply a question mark with the battery icon.

There are two issues cause these problems:

the power_supply sysfs paths used by the batteryservice jni layer are not correct. Current sysfs path for battery status is hardcoded inside com_android_server_BatteryService.cpp and it is for G1 only.
The way how Android handles the content of battery status files in sysfs may not be right for your machine. For example, ACPI used by x86 has a different way to provide battery charging level. It is (charge_now/charge_full)*100. But G1 phone only has one parameter, and it is current charging level in a scale of 100.

Fixing these issues are not difficult, yet the hard part is how to make the fix portable, what about tomorrow you want the same code to work on a different platform?
It is for sure not a good idea to continue to hardcode for the sysfs path or content processing methods inside com_android_BatteryService.cpp again.

Here is my 2 cents:
We could put power_supply sysfs paths inside vendor/asus/eee_701/system.prop and then have com_android_BatteryService.cpp pick them up from system property during the run time. By doing this, you don't need to change any of your code, if you add new type of battery with different sysfs path, you don't even need to change your code.
Now, you may want to ask me what about processing the file contents differently? For that, we may need to do more works. We could create an abstract class that can be inherited by the real battery status class. The abstract class implements the battery status common interface and methods. The real battery status class will only need to implement the special parts for different battery. And the BatteryService jni layer calls the real battery status class to collect battery status. So when you have a new battery, only a minimum mount of the code need to be changed.

I have actually implemented the entire thing and the same code works on G1, EeePC and VirtualBox very well.