Android on X86 Battery Service problem

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:

1. 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.
2. 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.