What to do about all those buttons?

by Peter Eastman » Wed, 27 Jan 2010 03:15:03 GMT

Sponsored Links
 his is partly a rant, partly a set of suggestions, and partly an
attempt to start a discussion on how to improve a basic part of the
Android UI. But to skip straight to the punch line: Android phones
have too many physical buttons on them, and those button don't work
very well. Now let me back up and explain why.

When Apple designed the iPhone, they decided to completely do away
with physical buttons. Instead, they would have a touch screen that
allowed infinitely configurable UIs. Each application could have
whatever buttons were appropriate for it. This was a very good idea
that worked very well in practice, but they did end up making one
exception: the Home button. They decided that, no matter what options
an application offered at a particular time, you always needed a way
to get out of it, and the only way to guarantee that was with a
physical button.

When Google developed Android, they decided that one button might be
enough for Apple, but it wasn't enough for them. Why? Who knows?
Maybe they just thought more was better. It reminds me a bit of the
mid 80s. When Apple introduced the personal computer mouse, they made
a big point of the fact that it only had one button. "All you need to
do is point and click." But Microsoft decided that Windows mice would
have two buttons, and thus would be more powerful than Macintosh
mice. And then Unix system vendors of course had to make their
computers even more powerful, so Unix mice all had three buttons! Of
course, this didn't actually make them more powerful. It just made
them a lot more confusing to use.

So let's look at the four buttons found on every Android device: Home,
Menu, Back, and Search. Do they really belong there? Do they do more
to help or hurt the user interface?

First is the Home button, the one button Apple felt was required. I
agree with their judgement, and have nothing to say against it. So
let's move on.

Next is the Menu button. I can understand the logic behind it: lots
of applications need to display menus, so it makes sense to provide a
standard mechanism for bringing them up. That sounds reasonable. So
what's wrong with it.

Well, first there's just the fact that it's unnecessary. If an
application wants to offer a menu, an on-screen button would work just
as well. But much more importantly, it turns every menu into a hidden
feature. There is absolutely no way to tell when a menu is
available. The user needs to just happen to wonder, "Does this screen
have a menu?", then try pressing the Menu button to find out. That is
simply a bad user interface.

What can we do about this? It's probably too late to get rid of the
Menu button, but there are several ways to improve the situation. One
is for developers not to rely on it. If you want to make a menu
available, provide an on-screen button as an alternative to the Menu
button. Another option is to establish a standard indication to tell
the user when a menu is available. Perhaps this could be a standard
icon somewhere on the screen, or maybe the Menu button could light
up. But users really need to be told when a menu is available. They
shouldn't be required to guess.

Next comes the Back button. At first glance, this seems reasonable.
The idea of a Back button is familiar to anyone who has used a web
browser, and it works very well there. So why not here?

The problem is that the Back button doesn

What to do about all those buttons?

by Matt Kanninen » Wed, 27 Jan 2010 08:20:48 GMT

  could not agree less.  One of my biggest gripes about my Droid is
that the 4 buttons, which I use all the time, are virtual soft keys,
not real buttons. I also miss the Green send and Red hangup button.

Also I'd just like to say, on all phones you should be able to hit the
green send button to answer the phone without having to unlock it
first. You should have to unlock to initiate a call. That way you
won't pocket dial, but you will be able to answer a phone without
having to look at it.

On Jan 23, 10:14pm, Peter Eastman <peter.east...@gmail.com> wrote:


Sponsored Links

What to do about all those buttons?

by Simon Jagoe » Wed, 27 Jan 2010 08:45:12 GMT

 I don't disagree with questioning the UI design. I think it would be a
good idea to give users an indication of when a menu is available, for
example, but I think that saying those buttons should be removed is
taking it a little far. The only one I have had trouble with is
search. And that only because I forget that it is there (this nexus
one being my first android phone). I think when I get used to it I
will make more use of it. I have fired up the browser a lot and
started searching from within it when I could just hit that button.

I find the behaviour of the back button to be quite good and
predictable. If I have been reading email and follow a link, the
browser opens. I click back and I am taken back to my email. If I
instead press home and open my calendar then as you say, pressing back
takes me to the home screen. I think this is better than going to
email because there could be hours between pressing home from the
first task and beginning the second. Say the first task was in the
evening and the second was in the morning after waking up. If the
phone randomly took me into my email when I pressed back, I would
think it had gone mad and there was some obscure bug in the back
button behaviour.

And for the record I don't think Apple is the king of UI design. The
iPhone is probably a good example of where they got it quite right,
but there are also arguments for the physical buttons. An app
developer does not need to draw toolbars or button boxes and design
these elements into the UI. Maybe that is a silly reason, I'm sure
there are others.


What to do about all those buttons?

by Peter Eastman » Wed, 27 Jan 2010 09:56:50 GMT

 > If I instead press home and open my calendar then as you say, pressing back

As it should.  That is consistent with the interpretation of Back as
"take me back to where I was before."  Before opening the calendar you
were on the Home screen, so that is where Back should take you to.

The example I gave was a different situation: you press Home, then
Back without opening any other application.  In that case, it ought to
take you back to where you were when you pressed the Home button.
That is consistent with the idea of "take me back to where I was
before."  But that isn't what it actually does.  In fact, it doesn't
do anything at all.



What to do about all those buttons?

by Zero » Wed, 27 Jan 2010 19:40:36 GMT

 yeah, flamewar time !
i couldn't disagree more.
a mouse with only one button is useless crap.
a phone with only one button is....

it's ok if you prefer the way apple designs things over everything
else, i do not.
so please, don't question valid design decisions made on other
simply because they are not to the liking of the apple fan boys.


What to do about all those buttons?

by Streets Of Boston » Thu, 28 Jan 2010 03:56:04 GMT

 The Back button takes you back until your reach home, just like a web-

Menu button allows you to save some real-estate on the screen.
Blackberry users are used to it. WinMobile users are used to it.

All your points are valid, but they are a specific choice of UI-design
and i don't think that either choice (iPhone vs Android) is wrong.
They're just different.


What to do about all those buttons?

by Peter Eastman » Thu, 28 Jan 2010 06:55:15 GMT



I'm not interested in a flamewar, and please don't attribute things to
me that I didn't say.  I don't believe that everyone must do things
exactly the way Apple does (after all, I chose to buy a Nexus One
rather than an iPhone), but I also believe we can all learn by looking
at the solutions other people have found to common problems.  I don't
believe that more buttons or fewer buttons is inherently better, but I
do believe that designs can be rationally compared and, when one
design is objectively better than another one, we should use it.

For example, is it better to have a physical Menu button, or to use an
on-screen Menu button?  Either one could be implemented well or
implemented badly, but Android's implementation is objectively
inferior to Apple's implementation in a very important way: users have
no way to know when a menu is available, and that significantly harms
the usability of Android devices.  I also believe there are ways of
improving the implementation to eliminate this problem, and I made
some specific suggestions for ways to do it.



What to do about all those buttons?

by Matt Kanninen » Thu, 28 Jan 2010 07:21:19 GMT

 esponses are in line and I snipped a lot.

On Jan 27, 2:54pm, Peter Eastman <peter.east...@gmail.com> wrote:

I believe we all need to look at the iPad. Dissect it. Root it.
Reverse Engineer it. Challenge the Apple p...@t3ntz. Risk pissing off

Physical button. The answer is almost always physical button, but you
don't want more then 26+10+4+5+2+2 buttons where x is user
26 letters, 10 numbers, the 4 Android buttons, an up, down, left,
right and center button, a volume up, a volume down, an answer and a
hangup button. I also like a period, an @ sign, a shift key, and a
trackball myself.

We are teaching users to always check the menu button. Some
developers don't use it, but that is not a Framework or a User error,
it is a Developer error.

On Jan 26, 5:56 pm, Peter Eastman <peter.east...@gmail.com> wrote:

Home means clear the stack. Back should do nothing after you clear
the stack. What does home mean to you? If you want similar
functionality to Home without clearing the stack you can long press
the home.

On Android "Exit" is "hit back 7x". It should only take them back
until the last time they hit Home.

On Jan 27, 3:40 am, Zero <zeroo...@googlemail.com> wrote:

A phone with only one button is crap. You need at least 2, 1 to
answer and 1 to hangup.

Do there already exist apps that let you use an Android device as a
keyboard for a text editor, which is displayed on an iPhone screen?
I'd like to use my iPad as a screen, and my Droid as my UI. I'm
willing to slave a Windows PC in the middle if I have to.

-Matt Kanninen
-Mobile Developer


What to do about all those buttons?

by Peter Eastman » Thu, 28 Jan 2010 07:33:08 GMT

 On Jan 27, 11:55am, Streets Of Boston <flyingdutc...@gmail.com>

Is it really just like a web browser?  Consider it carefully.

Suppose your home page is "mycoolpage.me.com".  So you start up your
web browser and it takes you there.  Now you spend a while browsing
the web, looking at different pages.  Then you decide you want to
check something on your home page, so you type "mycoolpage.me.com"
into the address bar and takes you there.

Ok, you checked what you wanted to, and now you want to get back to
what you were browsing before, so you hit the back button.  Does the
web browser decide that, since you've come back to your home page, you
can't go back any further and therefore the back button should be
ignored?  Of course not.  It takes you back to whatever page you were
on before.  And I'm suggesting Android should do the same thing.



What to do about all those buttons?

by Peter Eastman » Thu, 28 Jan 2010 07:44:56 GMT


That reminds me of the standard UI designer's joke: "Let me explain to
you why this is intuitive!"  If you have to explain it, then it's not
intuitive, and if you have to teach users to do something, then it's
not intuitive.  And even if you teach them, why should they have to
take the trouble to check whether a menu's available?  Why can't we
just tell them?  (Answer: There's no reason we can't, and we should.)

I understand that's what it means, but only because I've read the
developer documentation.  The problem is that it isn't what users
expect it to mean.  In a web browser, Home means, "Take me to my home
page," and Back means, "Take me back to where I was before."

Long pressing the Home button has exactly the same problem.  I'm
working in application A.  Then I switch to application B.  Then I
press Back and it takes me to... the home screen???



What to do about all those buttons?

by Matt Kanninen » Thu, 28 Jan 2010 09:17:24 GMT

 Users expected multitouch to be impossible.  Users still expect
multitasking to fail.  It is intuitive if it sucks, users expect it to
suck.  Intuitive does not mean good.  Intuitive today is not the same
as intuitive last year or next year.

Apple had to explain a great deal to users.  Now that they have done
that we have to explain to the users why Apple was wrong.  The user's
intuition is, unfortunately, off.  It has been heavily influenced by
bad design.

Android has much looser constraints then the iPhone.  I am impressed
that Apple claims that 100k + iPhone apps will be available on the
iPad.  Especially since when I was working on an iPhone app I did not
even know I was working on an iPad app.  I guess I need to go back and
change my resume, I am now an iPad developer, retroactively!


What to do about all those buttons?

by Streets Of Boston » Thu, 28 Jan 2010 12:20:21 GMT

 >so you type "mycoolpage.me.com" into the address bar and takes you there.<
Typing is just like a navigation-action, like clicking a link. I see
no difference. In the end, the home page is where you opened the

In your example, typing to go to "mycoolpage.me.com" does not make
"mycoolpage.me.com" your new home-page. Your home page is still the
page that opened when your browser started.

Same in Android:
If i am in my application (activity) and i get a phone-call, the Phone-
activity is shown. After the call, when i press back, my original
application (activity) is shown again.


What to do about all those buttons?

by Peter Eastman » Fri, 29 Jan 2010 05:05:14 GMT


Exactly.  It sounds like we're actually saying the same thing.  In a
web browser, if you press Home then press Back, it takes you back to
wherever you were before you pressed Home.  Would you agree that
Android should work the same way?  If so, then we're in complete



What to do about all those buttons?

by Peter Eastman » Fri, 29 Jan 2010 05:07:15 GMT


Could you explain?  What are the bad designs you think users have been
influenced by?  What aspects of their intuition do you think need to
be challenged?



What to do about all those buttons?

by Streets Of Boston » Fri, 29 Jan 2010 12:07:09 GMT

 But that's what i described in my second part of my previous post:
Android *does* work the same way:

activity is shown. After the call, when i press back, my original
application (activity) is shown again."<<

where "my application" is like my current browser session and "phone-
activity" is like navigating to 'mycoolpage.me.com'.

When you hit back enough times, you'll hit the page that was opened
when the browser was started, and even in the browser you won't go
'back' to anything anymore.

I will give you this: :-)
If you hit 'Home' in the browser after doing some other browsing, you
can click the 'Back' button, bringing you back to the page you were
previously on. The 'Home' button in a browser is like a navigation...
it does not clear the stack.


Other Threads

1. Where to find native resources?

Could someone please tell me how to access android's native resources?
In particular, I would like to use the camera icon and shutter sound
in my own app.

2. Patches for android-1.5r2 for gumstix overo + palo43 platform

      Here is a work in progress patch set for getting android to run
on the gumstix overo TI OMAP3503 processor, using the gumstix Palo43
expansion board.

Elvis Dowson

project bionic/
diff --git a/libc/private/bionic_tls.h b/libc/private/bionic_tls.h
index da34344..ba86d2a 100644
--- a/libc/private/bionic_tls.h
+++ b/libc/private/bionic_tls.h
@@ -81,7 +81,8 @@ extern int __set_tls(void *ptr);

 /* get the TLS */
 #ifdef __arm__
-#  define __get_tls() ( *((volatile void **) 0xffff0ff0) )
+typedef void* (__get_tls_t)(void);
+static const __get_tls_t* __get_tls = (const __get_tls_t *)
 extern void*  __get_tls( void );

project external/qemu/
diff --git a/Makefile.android b/Makefile.android
index 4c697fb..98d2084 100644
--- a/Makefile.android
+++ b/Makefile.android
@@ -18,7 +18,7 @@ MY_CFLAGS := $(CONFIG_INCLUDES) -O2 -g \

 # this is needed to build the emulator on 64-bit Linux systems
 ifeq ($(HOST_OS)-$(HOST_ARCH),linux-x86)
-  MY_CFLAGS += -Wa,--32
+  MY_CFLAGS += -Wa,--32 -D_GNU_SOURCE

 ifeq ($(HOST_OS),freebsd)

project frameworks/base/
diff --git a/include/ui/EGLDisplaySurface.h b/include/ui/
index a8b5853..002a940 100644
--- a/include/ui/EGLDisplaySurface.h
+++ b/include/ui/EGLDisplaySurface.h
@@ -25,7 +25,8 @@
 #include <ui/EGLNativeSurface.h>

 #include <pixelflinger/pixelflinger.h>
-#include <linux/fb.h>
+#include <linux-omap3/fb.h>
+#include <linux-omap3/omapfb.h>

 #include <EGL/egl.h>

diff --git a/libs/surfaceflinger/DisplayHardware/DisplayHardware.cpp b/
index f14d7e9..85d81b6 100644
--- a/libs/surfaceflinger/DisplayHardware/DisplayHardware.cpp
+++ b/libs/surfaceflinger/DisplayHardware/DisplayHardware.cpp
@@ -138,7 +138,7 @@ void DisplayHardware::init(uint32_t dpy)
     const char* const egl_extensions = eglQueryString(
             display, EGL_EXTENSIONS);

-    LOGI("EGL informations:");
+    LOGI("OpenGL ES information:");
     LOGI("# of configs : %d", numConfigs);
     LOGI("vendor    : %s", eglQueryString(display, EGL_VENDOR));
     LOGI("version   : %s", eglQueryString(display, EGL_VERSION));
@@ -163,7 +163,7 @@ void DisplayHardware::init(uint32_t dpy)
     mDisplaySurface = new EGLDisplaySurface();

     surface = eglCreateWindowSurface(display, config,
mDisplaySurface.get(), NULL);
-    //checkEGLErrors("eglCreateDisplaySurfaceANDROID");
+    checkEGLErrors("eglCreateDisplaySurfaceANDROID");

     if (eglQuerySurface(display, surface, EGL_SWAP_BEHAVIOR, &dummy)
== EGL_TRUE) {
         if (dummy == EGL_BUFFER_PRESERVED) {
@@ -201,7 +201,7 @@ void DisplayHardware::init(uint32_t dpy)

     context = eglCreateContext(display, config, NULL, NULL);
-    //checkEGLErrors("eglCreateContext");
+    checkEGLErrors("eglCreateContext");

     eglQuerySurface(display, surface, EGL_WIDTH, &mWidth);
     eglQuerySurface(display, surface, EGL_HEIGHT, &mHeight);
diff --git a/libs/ui/EGLDisplaySurface.cpp b/libs/ui/
index d06c98b..ec406c6 100644
--- a/libs/ui/EGLDisplaySurface.cpp
+++ b/libs/ui/EGLDisplaySurface.cpp
@@ -175,8 +175,14 @@ uint32_t EGLDisplaySurface::swapBuffers()
     mIndex = 1 - mIndex;
     mInfo.activate = FB_ACTIVATE_VBL;
     mInfo.yoffset = mIndex ? mInfo.yres : 0;
-    if (ioctl(egl_native_window_t::fd, FBIOPUT_VSCREENINFO, &mInfo)
== -1) {
-        LOGE("FBIOPUT_VSCREENINFO failed");
+    if (ioctl(egl_native_window_t::fd, FBIOPAN_DISPLAY, &mInfo) ==
-1) {
+        LOGE("FBIOPAN_DISPLAY failed");
+        return 0;
+    }
+    // Wait for vertical blanking interval, to reduce tearing and
flicker artifacts.
+    if (ioctl(egl_native_window_t::fd, OMAPFB_WAITFORVSYNC, &mInfo)
== -1) {
         return 0;

@@ -395,10 +401,10 @@ status_t EGLDisplaySurface::mapFrameBuffer()
     info.activate = FB_ACTIVATE_NOW;

     uint32_t flags = PAGE_FLIP;
-    if (ioctl(fd, FBIOPUT_VSCREENINFO, &info) == -1) {
+    if (ioctl(fd, FBIOPAN_DISPLAY, &info) == -1) {
         info.yres_virtual = info.yres;
         flags &= ~PAGE_FLIP;
-        LOGW("FBIOPUT_VSCREENINFO failed, page flipping not
+        LOGW("FBIOPAN_DISPLAY failed, page flipping not supported");

     if (info.yres_virtual < info.yres * 2) {
diff --git a/libs/ui/EventHub.cpp b/libs/ui/EventHub.cpp
index 7c2fc8e..bedc2d2 100644
--- a/libs/ui/EventHub.cpp
+++ b/libs/ui/EventHub.cpp
@@ -517,7 +517,7 @@ int EventHub::open_device(const char *deviceName)
     mFDs = new_mFDs;
     mDevices = new_devices;

-#if 0
+#if 1
     LOGI("add device %d: %s\n", mFDCount, deviceName);
     LOGI("  bus:      %04x\n"
          "  vendor    %04x\n"
diff --git a/opengl/libs/Android.mk b/opengl/libs/Android.mk
index 2ecc776..20444e6 100644
--- a/opengl/libs/Android.mk
+++ b/opengl/libs/Android.mk
@@ -34,7 +34,7 @@ include $(BUILD_SHARED_LIBRARY)
 include $(CLEAR_VARS)

-       GLES_CM/gl.cpp.arm              \
+       GLES_CM/gl.cpp          \
        GLES_CM/gl_logger.cpp   \

diff --git a/opengl/libs/GLES_CM/gl.cpp b/opengl/libs/GLES_CM/gl.cpp
index 865cf44..35478f0 100644
--- a/opengl/libs/GLES_CM/gl.cpp
+++ b/opengl/libs/GLES_CM/gl.cpp
@@ -68,7 +68,7 @@ void glVertexPointerBounds(GLint size, GLenum type,
 #undef CALL_GL_API


     #define API_ENTRY(_api) __attribute__(({*filter*})) _api

@@ -90,7 +90,7 @@ void glVertexPointerBounds(GLint size, GLenum type,
         CALL_GL_API(_api, __VA_ARGS__) \
         return 0; // placate gcc's warnings. never reached.

+#else */

     #define API_ENTRY(_api) _api

@@ -104,7 +104,7 @@ void glVertexPointerBounds(GLint size, GLenum
         GL_LOGGER_IMPL( log_##_api
(__VA_ARGS__); )                      \
         return _c->_api(__VA_ARGS__)


 extern "C" {
 #include "gl_api.in"
diff --git a/services/java/com/android/server/InputDevice.java b/
index 7b8a2a4..d9304c1 100644
--- a/services/java/com/android/server/InputDevice.java
+++ b/services/java/com/android/server/InputDevice.java
@@ -21,10 +21,15 @@ import android.view.Display;
 import android.view.MotionEvent;
 import android.view.Surface;
 import android.view.WindowManagerPolicy;
+import java.io.FileInputStream;
+import java.util.StringTokenizer;

 public class InputDevice {
     /** Amount that trackball needs to move in order to generate a
key event. */
     static final int TRACKBALL_MOVEMENT_THRESHOLD = 6;
+    /** Touchscreen calibration file. */
+    static final String CALIBRATION_FILE = "/etc/pointercal";

     final int id;
     final int classes;
@@ -33,6 +38,7 @@ public class InputDevice {
     final AbsoluteInfo absY;
     final AbsoluteInfo absPressure;
     final AbsoluteInfo absSize;
+    final TransformInfo tInfo;

     long mDownTime = 0;
     int mMetaKeysState = 0;
@@ -86,12 +92,24 @@ public class InputDevice {
                     h = tmp;
                 if (device.absX != null) {
-                    scaledX = ((scaledX-device.absX.minValue)
-                                / device.absX.range) * w;
+                   if (device.tInfo != null)
+                       scaledX = (device.tInfo.x1 * x +
+                                          device.tInfo.y1 * y +
+                                   device.tInfo.z1)
+                                  / device.tInfo.s;
+                   else
+                       scaledX = ((scaledX-device.absX.minValue)
+                                    / device.absX.range) * w;
                 if (device.absY != null) {
-                    scaledY = ((scaledY-device.absY.minValue)
-                                / device.absY.range) * h;
+                   if (device.tInfo != null)
+                       scaledY = (device.tInfo.x2 * x +
+                                          device.tInfo.y2 * y +
+                                   device.tInfo.z2)
+                                  / device.tInfo.s;
+                   else
+                       scaledY = ((scaledY-device.absY.minValue)
+                                    / device.absY.range) * h;
                 if (device.absPressure != null) {
                     scaledPressure =
@@ -199,6 +217,16 @@ public class InputDevice {
         int fuzz;

+    static class TransformInfo {
+        float x1;
+        float y1;
+        float z1;
+        float x2;
+        float y2;
+       float z2;
+       float s;
+    };
     InputDevice(int _id, int _classes, String _name,
             AbsoluteInfo _absX, AbsoluteInfo _absY,
             AbsoluteInfo _absPressure, AbsoluteInfo _absSize) {
@@ -209,5 +237,38 @@ public class InputDevice {
         absY = _absY;
         absPressure = _absPressure;
         absSize = _absSize;
+       TransformInfo t = null;
+       try {
+               FileInputStream is = new FileInputStream(CALIBRATION_FILE);
+               byte[] mBuffer = new byte[64];
+               int len = is.read(mBuffer);
+               is.close();
+               if (len > 0) {
+                   int i;
+                   for (i = 0 ; i < len ; i++) {
+                       if (mBuffer[i] == '\n' || mBuffer[i] == 0) {
+                               break;
+                       }
+                   }
+                   len = i;
+               }
+               StringTokenizer st = new StringTokenizer( new String(mBuffer, 
0, 0,
len) );
+               t       = new TransformInfo ();
+               t.x1    = Integer.parseInt( st.nextToken() );
+               t.y1    = Integer.parseInt( st.nextToken() );
+               t.z1    = Integer.parseInt( st.nextToken() );
+               t.x2    = Integer.parseInt( st.nextToken() );
+               t.y2    = Integer.parseInt( st.nextToken() );
+               t.z2    = Integer.parseInt( st.nextToken() );
+               t.s     = Integer.parseInt( st.nextToken() );
+       } catch (java.io.FileNotFoundException e) {
+       } catch (java.io.IOException e) {
+       }
+       tInfo = t;
diff --git a/services/jni/com_android_server_BatteryService.cpp b/
index 6636a97..748f514 100644
--- a/services/jni/com_android_server_BatteryService.cpp
+++ b/services/jni/com_android_server_BatteryService.cpp
@@ -150,12 +150,12 @@ static void setBooleanField(JNIEnv* env, jobject
obj, const char* path, jfieldID
     const int SIZE = 16;
     char buf[SIZE];

-    jboolean value = false;
-    if (readFromFile(path, buf, SIZE) > 0) {
+    jboolean value = true;
+/*    if (readFromFile(path, buf, SIZE) > 0) {
         if (buf[0] == '1') {
             value = true;
-    }
+    } */
     env->SetBooleanField(obj, fieldID, value);

@@ -164,10 +164,10 @@ static void setIntField(JNIEnv* env, jobject
obj, const char* path, jfieldID fie
     const int SIZE = 128;
     char buf[SIZE];

-    jint value = 0;
-    if (readFromFile(path, buf, SIZE) > 0) {
+    jint value = 100;
+/*    if (readFromFile(path, buf, SIZE) > 0) {
         value = atoi(buf);
-    }
+    } */
     env->SetIntField(obj, fieldID, value);

@@ -181,17 +181,21 @@ static void android_server_BatteryService_update
(JNIEnv* env, jobject obj)
     setIntField(env, obj, BATTERY_VOLTAGE_PATH,
     setIntField(env, obj, BATTERY_TEMPERATURE_PATH,

+    env->SetIntField(obj, gFieldIds.mBatteryStatus,
+    env->SetIntField(obj, gFieldIds.mBatteryHealth,
+    env->SetObjectField(obj, gFieldIds.mBatteryTechnology, env-
     const int SIZE = 128;
     char buf[SIZE];

-    if (readFromFile(BATTERY_STATUS_PATH, buf, SIZE) > 0)
+/*    if (readFromFile(BATTERY_STATUS_PATH, buf, SIZE) > 0)
         env->SetIntField(obj, gFieldIds.mBatteryStatus,

     if (readFromFile(BATTERY_HEALTH_PATH, buf, SIZE) > 0)
         env->SetIntField(obj, gFieldIds.mBatteryHealth,

     if (readFromFile(BATTERY_TECHNOLOGY_PATH, buf, SIZE) > 0)
-        env->SetObjectField(obj, gFieldIds.mBatteryTechnology, env-
+        env->SetObjectField(obj, gFieldIds.mBatteryTechnology, env-

 static JNINativeMethod sMethods[] = {

unsubscribe: android-porting+unsubscr...@googlegroups.com
website:  http://www.***.com/ 

3. problem in receiving the status of call

4. Camera API: Excessive GC caused by preview callbacks

5. The end of Netbook Android?

6. Memory leak in AudioTrack?

7. Canvas.drawText failing to draw on a second call