RE : Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Here's a crashlog. It happened on n1 after a rotation. Looks like the swap function is called with a wrong arg. 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new EGL 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new display 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new config 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) creating new context 04/08/2010 09:30:01 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new EGL 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new display 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new config 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) creating new context 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:30:03 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:04 [WARNING] SLWP(465) Texture Load GLError: 1284 04/08/2010 09:30:07 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:09 [WARNING] SLWP(465) Texture Load GLError: 1284 04/08/2010 09:30:22 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:24 [WARNING] SLWP(465) Texture Load GLError: 1284 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:30:42 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:38:34 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:39:19 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:41:46 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:43:00 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:43:58 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:44:02 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:44:07 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:44:09 [WARNING] SLWP(465) Texture Load GLError: 1384584 04/08/2010 09:44:09 [ERROR] AndroidRuntime(465) java.lang.IllegalArgumentException at com.google.android.gles_jni.EGLImpl.eglSwapBuffers(Native Method) at com.seb.SLWP.EglHelper.swap(GLWallpaperService.java:446) at com.seb.SLWP.GLThread.guardedRun(GLWallpaperService.java:687) at com.seb.SLWP.GLThread.run(GLWallpaperService.java:539) 04/08/2010 09:44:11 [INFORMATION] ActivityManager(106) Process com.seb.SLWP (pid
Re: RE : Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
What's up with those 1281s? On Apr 8, 2:53 am, seb boyart unix...@gmail.com wrote: Here's a crashlog. It happened on n1 after a rotation. Looks like the swap function is called with a wrong arg. 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new EGL 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new display 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) getting new config 04/08/2010 09:30:00 [DEBUG] EglHelperSLWP(465) creating new context 04/08/2010 09:30:01 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new EGL 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new display 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) getting new config 04/08/2010 09:30:02 [DEBUG] EglHelperSLWP(465) creating new context 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:30:03 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:30:03 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:04 [WARNING] SLWP(465) Texture Load GLError: 1284 04/08/2010 09:30:07 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:09 [WARNING] SLWP(465) Texture Load GLError: 1284 04/08/2010 09:30:22 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:24 [WARNING] SLWP(465) Texture Load GLError: 1284 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:30:27 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:30:42 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:30:46 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:38:34 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:38:39 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:39:19 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:39:26 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:41:46 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:41:50 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:43:00 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:43:21 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:43:58 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:44:01 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:44:02 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:44:07 [WARNING] SLWP(465) Background Load GLError: 1281 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) start() 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing EGL 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing display 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing config 04/08/2010 09:44:08 [DEBUG] EglHelperSLWP(465) reusing context 04/08/2010 09:44:09 [WARNING] SLWP(465) Texture Load GLError: 1384584 04/08/2010 09:44:09 [ERROR] AndroidRuntime(465) java.lang.IllegalArgumentException at com.google.android.gles_jni.EGLImpl.eglSwapBuffers(Native Method) at com.seb.SLWP.EglHelper.swap(GLWallpaperService.java:446) at
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )
On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}
mEglSurface = null;
}
In GLThread:
private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}
Basically, you don't want a finish() in there.
But we do need to finish somewhere so,
At the end of guardedRun():
} finally {
/*
* clean-up everything...
*/
synchronized (sGLThreadManager) {
// Log.d(GLThread + getId(), Finishing.);
stopEglLocked();
mEglHelper.finish();
}
}
}
Then Finally in GLWallpaperService:
@Override
public void onDestroy() {
super.onDestroy();
mGLThread.requestExitAndWait();
}
Of course you can remove any logging you don't want.
The idea here is that we get to reuse the display and context on
orientation changes which seems to make the Droid happy. I haven't
had a single crash since I switched to that, and I've probably
reoriented 100 times since then in testing.
I'll update the post on my blog to contain all the current code.
On Apr 6, 2:57 pm, Robert Green rbgrn@gmail.com wrote:
By the way - things seemed good but I'm still having the occasional
lock-up. The last one caused the phone to lock up badly enough that I
had to pull the battery :(
On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
I'm in disbelief, but it works! Why does that hack work? Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes? I don't quite understand but I guess I never
checked the return value of that call (because it wasn't returning
when I was having problems, but maybe it was too late then :)).
I tested and tested and tested again and this held up against all the
orientation changes I could possibly make. Good work! I'll update
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :
if (needStart) {
tellRendererSurfaceCreated = true;
changed = true;
}
if (changed) {
gl = (GL10)
mEglHelper.createSurface(mHolder);
tellRendererSurfaceChanged = true;
}
if (tellRendererSurfaceCreated) {
mRenderer.onSurfaceCreated(gl,
mEglHelper.mEglConfig);
tellRendererSurfaceCreated = false;
}
if (tellRendererSurfaceChanged) {
mRenderer.onSurfaceChanged(gl, w, h);
tellRendererSurfaceChanged = false;
}
On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )
On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}
mEglSurface = null;
}
In GLThread:
private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}
Basically, you don't want a finish() in there.
But we do need to finish somewhere so,
At the end of guardedRun():
} finally {
/*
* clean-up everything...
*/
synchronized (sGLThreadManager) {
// Log.d(GLThread + getId(), Finishing.);
stopEglLocked();
mEglHelper.finish();
}
}
}
Then Finally in
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
That's strange..
First of all, how are you getting orientation changes on an N1? I
never found a way to get it to do that.
I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now. It includes your wait-hack and my
updates.
On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :
if (needStart) {
tellRendererSurfaceCreated = true;
changed = true;
}
if (changed) {
gl = (GL10)
mEglHelper.createSurface(mHolder);
tellRendererSurfaceChanged = true;
}
if (tellRendererSurfaceCreated) {
mRenderer.onSurfaceCreated(gl,
mEglHelper.mEglConfig);
tellRendererSurfaceCreated = false;
}
if (tellRendererSurfaceChanged) {
mRenderer.onSurfaceChanged(gl, w, h);
tellRendererSurfaceChanged = false;
}
On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )
On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}
mEglSurface = null;
}
In GLThread:
private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}
Basically, you don't want a finish() in there.
But we do need to finish somewhere
RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
I use helixlauncher2 to rotate the desktop on n1.
Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :
That's strange..
First of all, how are you getting orientation changes on an N1? I
never found a way to get it to do that.
I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now. It includes your wait-hack and my
updates.
On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :
if (needStart) {
tellRendererSurfaceCreated = true;
changed = true;
}
if (changed) {
gl = (GL10)
mEglHelper.createSurface(mHolder);
tellRendererSurfaceChanged = true;
}
if (tellRendererSurfaceCreated) {
mRenderer.onSurfaceCreated(gl,
mEglHelper.mEglConfig);
tellRendererSurfaceCreated =
false;
}
if (tellRendererSurfaceChanged) {
mRenderer.onSurfaceChanged(gl, w,
h);
tellRendererSurfaceChanged =
false;
}
On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )
On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}
mEglSurface = null;
}
In GLThread:
private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
I didn't know about helixlauncher2. It's cool!
Now I can navigate the home screen just with the thumb. That never worked
reliable for me with the stock homescreen of the N1.
And everything is smooth. Feels like an iphone...
2010/4/7 seb boyart unix...@gmail.com
I use helixlauncher2 to rotate the desktop on n1.
Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :
That's strange..
First of all, how are you getting orientation changes on an N1? I
never found a way to get it to do that.
I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now. It includes your wait-hack and my
updates.
On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :
if (needStart) {
tellRendererSurfaceCreated = true;
changed = true;
}
if (changed) {
gl = (GL10)
mEglHelper.createSurface(mHolder);
tellRendererSurfaceChanged =
true;
}
if (tellRendererSurfaceCreated) {
mRenderer.onSurfaceCreated(gl,
mEglHelper.mEglConfig);
tellRendererSurfaceCreated =
false;
}
if (tellRendererSurfaceChanged) {
mRenderer.onSurfaceChanged(gl, w,
h);
tellRendererSurfaceChanged =
false;
}
On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )
On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
Re: RE : [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
forget it, your code is fine, it call the surfacechanged right, passing good
values for width and height.
for obvious reasons, my sphere isn't restreched after a rotation (it does
approx 5% of the time only), but all initialization is done
in surfacechanged using passed width and height, it worked fine before, but
not anymore.
anyway the code on the blog look fine, i just had to declare the instanceId
var and cast a return value to Runnable to compile it.
i'm gonna publish a commentary with a link to your blog in the code, do you
want something special in it ?
2010/4/7 seb boyart unix...@gmail.com
I use helixlauncher2 to rotate the desktop on n1.
Le 7 avr. 2010 23:01, Robert Green rbgrn@gmail.com a écrit :
That's strange..
First of all, how are you getting orientation changes on an N1? I
never found a way to get it to do that.
I tested my latest code on www.rbgrn.net on both the N1 and Droid and
both seem to be working well now. It includes your wait-hack and my
updates.
On Apr 7, 3:57 pm, unixseb unix...@gmail.com wrote:
i'm currently using the code on your blog, i have an issue on N1, when
the orientation change, the surfacechanged function of the rendrerer
isn't called, so i can't reset the frustum to the correct window size.
i guess it's around the following code, i'm trying to fix it :
if (needStart) {
tellRendererSurfaceCreated = true;
changed = true;
}
if (changed) {
gl = (GL10)
mEglHelper.createSurface(mHolder);
tellRendererSurfaceChanged =
true;
}
if (tellRendererSurfaceCreated) {
mRenderer.onSurfaceCreated(gl,
mEglHelper.mEglConfig);
tellRendererSurfaceCreated =
false;
}
if (tellRendererSurfaceChanged) {
mRenderer.onSurfaceChanged(gl, w,
h);
tellRendererSurfaceChanged =
false;
}
On 7 avr, 22:32, unixseb unix...@gmail.com wrote:
i can't tell you if my code works for the droid (i dont own one) but
it help fixing issues on the N1.
anyway i still have issues, sometimes it looks like i have 2 opengl
surfaces swapping from each other after a resume.
i'm gonna implement your modifications and tell you the effect on the
N1
Thanks a lot for everything, my work would have never exists without
yours ! (and sorry for my poor english ;) )
On 6 avr, 22:58, Robert Green rbgrn@gmail.com wrote:
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
have a look at the svn repository on code.google.com/project/earth- live-wallpaper the hack int the glwallpaperservice class avoid some crashes with screen rotation on droids. On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote: Oh, so you solved it?? What's the issue and what's the workaround? On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote: i can help you, i'm having this issue with earth live wallpaper. i tracked a bug in the swap function taht causes service dies, but i was looking for this one for a long time now ! On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperServicecode I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
Re: [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
I'm also interested in this topic. I got an 404 on the link: This seems to work: http://code.google.com/p/earth-live-wallpaper/ Thank you for sharing your code! 2010/4/6 unixseb unix...@gmail.com have a look at the svn repository on code.google.com/project/earth- live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper the hack int the glwallpaperservice class avoid some crashes with screen rotation on droids. On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote: Oh, so you solved it?? What's the issue and what's the workaround? On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote: i can help you, i'm having this issue with earth live wallpaper. i tracked a bug in the swap function taht causes service dies, but i was looking for this one for a long time now ! On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperServicecode I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Assuming I correctly identified the code that unixseb uses as the
workaround/fix for orientation changes on Droid in Live Wallpaper with
OpenGL, the following code is the same with the exception of
recursion:
public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
display, EGLConfig config, Object nativeWindow) {
EGLSurface eglSurface = null;
while (eglSurface == null) {
try {
eglSurface = egl.eglCreateWindowSurface(display,
config, nativeWindow, null);
} catch (Throwable t) {
} finally {
if (eglSurface == null) {
try {
Thread.sleep(10);
} catch (InterruptedException t) {
}
}
}
}
return eglSurface;
}
I'd like to know if unixseb's fix works for others. I still cannot
test.
On Apr 6, 11:00 am, Ralf Schneider li...@gestaltgeber.com wrote:
I'm also interested in this topic. I got an 404 on the link: This seems to
work:
http://code.google.com/p/earth-live-wallpaper/
Thank you for sharing your code!
2010/4/6 unixseb unix...@gmail.com
have a look at the svn repository on code.google.com/project/earth-
live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
the hack int the glwallpaperservice class avoid some crashes with
screen rotation on droids.
On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
Oh, so you solved it?? What's the issue and what's the workaround?
On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:
i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long time now !
On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:
I've had this reported to me by a few people using the
GLWallpaperServicecode I posted. I've been debugging this for hours
and have so far tracked the problem down to
egl.eglCreateWindowSurface(display, config, nativeWindow, null);
It never returns and every notifyAll() after that results in:
W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
timed out (identity=288, status=0). CPU may be pegged. trying again.
It seems to happen when switching orientation - so when the surface
is
being destroyed/recreated and more specifically when calls to render
the frame are being made at the same time. If there are no render
calls happening while switching, things seem mostly ok. I'm
debugging
this further but I feel like a method like that should never
deadlock. Seems like a bug somewhere below the line to me.
Since none of the GL init code from the shipped live wallpapers was
posted anywhere, I have no good reference to use for how to properly
handle the window resizing. Clearly the code I'm using does it a
little differently but I still feel like a deadlock like this should
not occur.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe, reply using remove me as the subject.- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
I'm in disbelief, but it works! Why does that hack work? Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes? I don't quite understand but I guess I never
checked the return value of that call (because it wasn't returning
when I was having problems, but maybe it was too late then :)).
I tested and tested and tested again and this held up against all the
orientation changes I could possibly make. Good work! I'll update
the code I posted.
BTW - I'm still seeing the occasional:
E/libEGL ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
(group=0x4001b180)
E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
due to uncaught exception
E/AndroidRuntime( 5769): java.lang.IllegalArgumentException
E/AndroidRuntime( 5769):at
com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib(Native Method)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$ComponentSizeChooser.findConfigAttrib(EglHelper.java:1007)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$ComponentSizeChooser.chooseConfig(EglHelper.java:987)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$BaseConfigChooser.chooseConfig(EglHelper.java:951)
E/AndroidRuntime( 5769):at
android.opengl.EglHelper.start(EglHelper.java:127)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$GLThread.guardedRun(EglHelper.java:421)
E/AndroidRuntime( 5769):at android.opengl.EglHelper
$GLThread.run(EglHelper.java:358)
I'm trying to track that one down but it's very hard to recreate. It
likes to happen the first time you run a newly installed gl live
wallpaper but then it doesn't happen again for a while.
Thanks guys for all your help!
On Apr 6, 11:29 am, shaun shashepp...@gmail.com wrote:
Assuming I correctly identified the code that unixseb uses as the
workaround/fix for orientation changes on Droid in Live Wallpaper with
OpenGL, the following code is the same with the exception of
recursion:
public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
display, EGLConfig config, Object nativeWindow) {
EGLSurface eglSurface = null;
while (eglSurface == null) {
try {
eglSurface = egl.eglCreateWindowSurface(display,
config, nativeWindow, null);
} catch (Throwable t) {
} finally {
if (eglSurface == null) {
try {
Thread.sleep(10);
} catch (InterruptedException t) {
}
}
}
}
return eglSurface;
}
I'd like to know if unixseb's fix works for others. I still cannot
test.
On Apr 6, 11:00 am, Ralf Schneider li...@gestaltgeber.com wrote:
I'm also interested in this topic. I got an 404 on the link: This seems to
work:
http://code.google.com/p/earth-live-wallpaper/
Thank you for sharing your code!
2010/4/6 unixseb unix...@gmail.com
have a look at the svn repository on code.google.com/project/earth-
live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
the hack int the glwallpaperservice class avoid some crashes with
screen rotation on droids.
On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
Oh, so you solved it?? What's the issue and what's the workaround?
On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:
i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long time now !
On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:
I've had this reported to me by a few people using the
GLWallpaperServicecode I posted. I've been debugging this for hours
and have so far tracked the problem down to
egl.eglCreateWindowSurface(display, config, nativeWindow, null);
It never returns and every notifyAll() after that results in:
W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
timed out (identity=288, status=0). CPU may be pegged. trying again.
It seems to happen when switching orientation - so when the surface
is
being destroyed/recreated and more specifically when calls to render
the frame are being made at the same time. If there are no render
calls happening while switching, things seem mostly ok. I'm
debugging
this further but I feel like a method like that should never
deadlock. Seems like a bug somewhere below the line to me.
Since none of the GL init code from the shipped live wallpapers was
posted anywhere, I have no good reference to use for how to properly
handle the window resizing. Clearly the code I'm using does it a
little
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
By the way - things seemed good but I'm still having the occasional
lock-up. The last one caused the phone to lock up badly enough that I
had to pull the battery :(
On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
I'm in disbelief, but it works! Why does that hack work? Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes? I don't quite understand but I guess I never
checked the return value of that call (because it wasn't returning
when I was having problems, but maybe it was too late then :)).
I tested and tested and tested again and this held up against all the
orientation changes I could possibly make. Good work! I'll update
the code I posted.
BTW - I'm still seeing the occasional:
E/libEGL ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
(group=0x4001b180)
E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
due to uncaught exception
E/AndroidRuntime( 5769): java.lang.IllegalArgumentException
E/AndroidRuntime( 5769): at
com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib(Native Method)
E/AndroidRuntime( 5769): at android.opengl.EglHelper
$ComponentSizeChooser.findConfigAttrib(EglHelper.java:1007)
E/AndroidRuntime( 5769): at android.opengl.EglHelper
$ComponentSizeChooser.chooseConfig(EglHelper.java:987)
E/AndroidRuntime( 5769): at android.opengl.EglHelper
$BaseConfigChooser.chooseConfig(EglHelper.java:951)
E/AndroidRuntime( 5769): at
android.opengl.EglHelper.start(EglHelper.java:127)
E/AndroidRuntime( 5769): at android.opengl.EglHelper
$GLThread.guardedRun(EglHelper.java:421)
E/AndroidRuntime( 5769): at android.opengl.EglHelper
$GLThread.run(EglHelper.java:358)
I'm trying to track that one down but it's very hard to recreate. It
likes to happen the first time you run a newly installed gl live
wallpaper but then it doesn't happen again for a while.
Thanks guys for all your help!
On Apr 6, 11:29 am, shaun shashepp...@gmail.com wrote:
Assuming I correctly identified the code that unixseb uses as the
workaround/fix for orientation changes on Droid in Live Wallpaper with
OpenGL, the following code is the same with the exception of
recursion:
public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay
display, EGLConfig config, Object nativeWindow) {
EGLSurface eglSurface = null;
while (eglSurface == null) {
try {
eglSurface = egl.eglCreateWindowSurface(display,
config, nativeWindow, null);
} catch (Throwable t) {
} finally {
if (eglSurface == null) {
try {
Thread.sleep(10);
} catch (InterruptedException t) {
}
}
}
}
return eglSurface;
}
I'd like to know if unixseb's fix works for others. I still cannot
test.
On Apr 6, 11:00 am, Ralf Schneider li...@gestaltgeber.com wrote:
I'm also interested in this topic. I got an 404 on the link: This seems to
work:
http://code.google.com/p/earth-live-wallpaper/
Thank you for sharing your code!
2010/4/6 unixseb unix...@gmail.com
have a look at the svn repository on code.google.com/project/earth-
live-wallpaper http://code.google.com/project/earth-%0Alive-wallpaper
the hack int the glwallpaperservice class avoid some crashes with
screen rotation on droids.
On 5 avr, 20:24, Robert Green rbgrn@gmail.com wrote:
Oh, so you solved it?? What's the issue and what's the workaround?
On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote:
i can help you,
i'm having this issue with earth live wallpaper.
i tracked a bug in the swap function taht causes service dies, but i
was looking for this one for a long time now !
On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote:
I've had this reported to me by a few people using the
GLWallpaperServicecode I posted. I've been debugging this for
hours
and have so far tracked the problem down to
egl.eglCreateWindowSurface(display, config, nativeWindow, null);
It never returns and every notifyAll() after that results in:
W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition)
timed out (identity=288, status=0). CPU may be pegged. trying
again.
It seems to happen when switching orientation - so when the
surface
is
being destroyed/recreated and more specifically when calls to
render
the frame are being made at the same time. If there are no render
calls happening while switching, things seem mostly ok. I'm
debugging
this further but
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}
mEglSurface = null;
}
In GLThread:
private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}
Basically, you don't want a finish() in there.
But we do need to finish somewhere so,
At the end of guardedRun():
} finally {
/*
* clean-up everything...
*/
synchronized (sGLThreadManager) {
// Log.d(GLThread + getId(), Finishing.);
stopEglLocked();
mEglHelper.finish();
}
}
}
Then Finally in GLWallpaperService:
@Override
public void onDestroy() {
super.onDestroy();
mGLThread.requestExitAndWait();
}
Of course you can remove any logging you don't want.
The idea here is that we get to reuse the display and context on
orientation changes which seems to make the Droid happy. I haven't
had a single crash since I switched to that, and I've probably
reoriented 100 times since then in testing.
I'll update the post on my blog to contain all the current code.
On Apr 6, 2:57 pm, Robert Green rbgrn@gmail.com wrote:
By the way - things seemed good but I'm still having the occasional
lock-up. The last one caused the phone to lock up badly enough that I
had to pull the battery :(
On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
I'm in disbelief, but it works! Why does that hack work? Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes? I don't quite understand but I guess I never
checked the return value of that call (because it wasn't returning
when I was having problems, but maybe it was too late then :)).
I tested and tested and tested again and this held up against all the
orientation changes I could possibly make. Good work! I'll update
the code I posted.
BTW - I'm still seeing the occasional:
E/libEGL ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
(group=0x4001b180)
E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
due to uncaught exception
E/AndroidRuntime( 5769): java.lang.IllegalArgumentException
E/AndroidRuntime( 5769): at
com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib(Native Method)
E/AndroidRuntime( 5769): at android.opengl.EglHelper
Re: [android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Thanks a lot Robert for tracking this down!
I'm planning to use the code from your web site, very soon.
2010/4/6 Robert Green rbgrn@gmail.com
That occasional lock-up started happening constantly to me. I messed
around with a few things and found that the Droid really doesn't like
to have its Display and Context destroyed all the time.
I modified the code so that it would reuse the display and context as
much as possible. I looked through my GLES book and it doesn't say
explicitly that you should always destroy them when your surface
changes so I have to assume that it must be ok. Even if it's not -
this works and it wasn't working before, so I'm using it.
Here are the code modifications:
In EglHelper:
public void start() {
Log.d(EglHelper + instanceId, start());
if (mEgl == null) {
Log.d(EglHelper + instanceId, getting new EGL);
/*
* Get an EGL instance
*/
mEgl = (EGL10) EGLContext.getEGL();
} else {
Log.d(EglHelper + instanceId, reusing EGL);
}
if (mEglDisplay == null) {
Log.d(EglHelper + instanceId, getting new display);
/*
* Get to the default display.
*/
mEglDisplay =
mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);
} else {
Log.d(EglHelper + instanceId, reusing display);
}
if (mEglConfig == null) {
Log.d(EglHelper + instanceId, getting new config);
/*
* We can now initialize EGL for that display
*/
int[] version = new int[2];
mEgl.eglInitialize(mEglDisplay, version);
mEglConfig = mEGLConfigChooser.chooseConfig(mEgl,
mEglDisplay);
} else {
Log.d(EglHelper + instanceId, reusing config);
}
if (mEglContext == null) {
Log.d(EglHelper + instanceId, creating new context);
/*
* Create an OpenGL ES context. This must be done only
once, an OpenGL context is a somewhat heavy object.
*/
mEglContext = mEGLContextFactory.createContext(mEgl,
mEglDisplay, mEglConfig);
if (mEglContext == null || mEglContext ==
EGL10.EGL_NO_CONTEXT) {
throw new RuntimeException(createContext failed);
}
} else {
Log.d(EglHelper + instanceId, reusing context);
}
mEglSurface = null;
}
In GLThread:
private void stopEglLocked() {
if (mHaveEgl) {
mHaveEgl = false;
mEglHelper.destroySurface();
sGLThreadManager.releaseEglSurface(this);
}
}
Basically, you don't want a finish() in there.
But we do need to finish somewhere so,
At the end of guardedRun():
} finally {
/*
* clean-up everything...
*/
synchronized (sGLThreadManager) {
// Log.d(GLThread + getId(), Finishing.);
stopEglLocked();
mEglHelper.finish();
}
}
}
Then Finally in GLWallpaperService:
@Override
public void onDestroy() {
super.onDestroy();
mGLThread.requestExitAndWait();
}
Of course you can remove any logging you don't want.
The idea here is that we get to reuse the display and context on
orientation changes which seems to make the Droid happy. I haven't
had a single crash since I switched to that, and I've probably
reoriented 100 times since then in testing.
I'll update the post on my blog to contain all the current code.
On Apr 6, 2:57 pm, Robert Green rbgrn@gmail.com wrote:
By the way - things seemed good but I'm still having the occasional
lock-up. The last one caused the phone to lock up badly enough that I
had to pull the battery :(
On Apr 6, 2:18 pm, Robert Green rbgrn@gmail.com wrote:
I'm in disbelief, but it works! Why does that hack work? Is it a
previous call to eglCreateWindowSurface which returns a bad value and
after that, cleaning up causes a bad state and the next call to create
window surface freezes? I don't quite understand but I guess I never
checked the return value of that call (because it wasn't returning
when I was having problems, but maybe it was too late then :)).
I tested and tested and tested again and this held up against all the
orientation changes I could possibly make. Good work! I'll update
the code I posted.
BTW - I'm still seeing the occasional:
E/libEGL ( 5769): eglChooseConfig:897 error 3005 (EGL_BAD_CONFIG)
W/dalvikvm( 5769): threadid=13: thread exiting with uncaught exception
(group=0x4001b180)
E/AndroidRuntime( 5769): Uncaught handler: thread GLThread 7 exiting
due to uncaught exception
E/AndroidRuntime( 5769):
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Can any of the authorities step in on this? So far no one has found or at least posted a solution to this problem. It's affecting several of the GL live wallpapers on the market right now (just look at comments on them - many complain of freezes on Droids) On Apr 4, 12:19 am, Robert Green rbgrn@gmail.com wrote: Lance, It does remind me of it but one of the first things I did when I started working on this issue was put the render/swap buffers into a synchronized block so that it would be guaranteed to be finished before any other call could interrupt/destroy the surface/etc. I just double-checked and I don't believe that it's the same issue as that bug. On Apr 3, 11:17 pm, Lance Nanek lna...@gmail.com wrote: Reminds me of this previous issue a little, where people were working out ways to make GLSurfaceView wait for the rendering to stop before actually pausing:http://code.google.com/p/android/issues/detail?id=4283 On Apr 3, 5:56 pm, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperService code I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
i can help you, i'm having this issue with earth live wallpaper. i tracked a bug in the swap function taht causes service dies, but i was looking for this one for a long time now ! On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperService code I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Oh, so you solved it?? What's the issue and what's the workaround? On Apr 4, 3:33 pm, unixseb unix...@gmail.com wrote: i can help you, i'm having this issue with earth live wallpaper. i tracked a bug in the swap function taht causes service dies, but i was looking for this one for a long time now ! On 3 avr, 23:56, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperService code I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Reminds me of this previous issue a little, where people were working out ways to make GLSurfaceView wait for the rendering to stop before actually pausing: http://code.google.com/p/android/issues/detail?id=4283 On Apr 3, 5:56 pm, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperService code I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Droid 2.1-update1 EGL10.eglCreateWindowSurface() deadlocks intermittently
Lance, It does remind me of it but one of the first things I did when I started working on this issue was put the render/swap buffers into a synchronized block so that it would be guaranteed to be finished before any other call could interrupt/destroy the surface/etc. I just double-checked and I don't believe that it's the same issue as that bug. On Apr 3, 11:17 pm, Lance Nanek lna...@gmail.com wrote: Reminds me of this previous issue a little, where people were working out ways to make GLSurfaceView wait for the rendering to stop before actually pausing:http://code.google.com/p/android/issues/detail?id=4283 On Apr 3, 5:56 pm, Robert Green rbgrn@gmail.com wrote: I've had this reported to me by a few people using the GLWallpaperService code I posted. I've been debugging this for hours and have so far tracked the problem down to egl.eglCreateWindowSurface(display, config, nativeWindow, null); It never returns and every notifyAll() after that results in: W/SharedBufferStack( 1030): waitForCondition(ReallocateCondition) timed out (identity=288, status=0). CPU may be pegged. trying again. It seems to happen when switching orientation - so when the surface is being destroyed/recreated and more specifically when calls to render the frame are being made at the same time. If there are no render calls happening while switching, things seem mostly ok. I'm debugging this further but I feel like a method like that should never deadlock. Seems like a bug somewhere below the line to me. Since none of the GL init code from the shipped live wallpapers was posted anywhere, I have no good reference to use for how to properly handle the window resizing. Clearly the code I'm using does it a little differently but I still feel like a deadlock like this should not occur. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject.
[android-developers] Re: Droid 2.1?
Not to burst your bubble, but my apps have seen the Google Nexus One and 2.1 for about a month now (found them looking through my Flurry stats). As for the Droid build part, well I guess we we're all expecting it to come eventually. Any one heard of an official release date? On Dec 28, 12:48 pm, Maps.Huge.Info (Maps API Guru) cor...@gmail.com wrote: I saw this as an agent today: Mozilla/5.0 (Linux; U; Android 2.1; en-us; Droid Build/ERD72) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/ 530.17 -John Coryat Radar Now! What Zip Code? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Droid 2.1?
Exactly , My application also sees 2.1. I can confirm it with Flurry stats also... On Mon, Dec 28, 2009 at 2:25 PM, theSmith chris.smith...@gmail.com wrote: Not to burst your bubble, but my apps have seen the Google Nexus One and 2.1 for about a month now (found them looking through my Flurry stats). As for the Droid build part, well I guess we we're all expecting it to come eventually. Any one heard of an official release date? On Dec 28, 12:48 pm, Maps.Huge.Info (Maps API Guru) cor...@gmail.com wrote: I saw this as an agent today: Mozilla/5.0 (Linux; U; Android 2.1; en-us; Droid Build/ERD72) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/ 530.17 -John Coryat Radar Now! What Zip Code? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Droid 2.1?
I've seen Nexus already, today was the first time I saw Droid with 2.1. Maybe a test device? -John Coryat -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Droid 2.1?
They ported the Nexus 2.1 build to the droid weeks ago over on alldroid. On Dec 28, 5:25 pm, Maps.Huge.Info (Maps API Guru) cor...@gmail.com wrote: I've seen Nexus already, today was the first time I saw Droid with 2.1. Maybe a test device? -John Coryat -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
