yashsingh1/xdaforums huggingface dataset:
[General Topics] DaveTheTytnIIGuy:
Yeah, I made a few provisioning XML files which contain all my email settings for my 3 accounts using Sashami. Register an account for the forum in the link (or otherwise obtain login credentials) and download the .cab. Install it, and open up Makisu (in the Sashami folder). Follow the wizard to create a provisioning XML file for an email account. When you're done, you should have an XML file which can be imported using tools like XDA User Customization during the initial boot (built into many cooked ROMs), Advanced Config, and Dotfred's Advanced Task Manager (though IIRC you have to rename the extension from .xml to .provxml to import with Dotfred's task manager). You can even make the XML file into a .cab by following these instructions (under "Creating the CAB File"), so you don't have to import it or change to a ROM with XDA_UC. This may seem like a lot of work right now, but you'll be grateful when you don't have to set up your email for the 70th time.
[General Topics] at45:
Thanks Dave. Sashimi is brilliant!
[Touch Pro2 CDMA] JohnnyFucknuts:
HTC has released the hotfix to correct the SMS issues with timestamps.

Since I can't post the url directly, go to HTC's web site and then go to:

/us/support/touch-pro2-sprint/downloads
[Touch Pro2 CDMA] WatermelonSlim:
It doesn't work on cooked ROMs...
[Touch Pro2 CDMA] HTCJake:
Sprint Direct Hotfix

Here it is direct from Sprint:

wwwDOTnextelDOTcom/en/software_downloads/pda_smartphone/htc_touch_pro2.shtml
[Nexus One Android Development] MarcusMaximus04@gmail.com:
I've been hankering to start porting a game I've been working on(originally was going to be for Zune HD but they haven't released the damn 3D SDK. Video of it running in windows is available on youtube, where my username is marcusmaximus04) to android but was hesitant due to the lack of OpenGL ES2.0 support in the Android SDK. However, looking through the file system on my nexus one, I spotted the file libGLESv2.so, which appears to be the shared object file for exactly this!

Obviously, I still can't use the normal SDK to use this, but in theory, one could use the NDK to use OpenGL ES 2.0 features(shaders, etc) through that shared object file.

The purpose of this post is three-fold. One I want to know if anyone has any background with using OpenGL through the NDK or knows of any tutorials for doing so(I'm not entirely sure how that would work...). Two, I wanted to bring this to the attention of all the devs out there who might be holding off from using ES 2.0 features. And three, I wanted to let everyone else know that such a thing is possible, just 'cause it's exciting.

At any rate, even if I can't find any tutorials I'll probably start plugging away at getting this to work and this should make for an exciting couple weeks/months.

Since we have this pretty well working(even on non-rooted phones) I'll post a sample apk. It doesn't look like much, but it does prove that we're using OpenGL ES 2.0(this will only work on the Nexus One). I'll also post the libGLESv2_adreno.so shared library in the same zip file. Enjoy :D.
[Nexus One Android Development] kozm0naut:
From http://developer.android.com/guide/topics/graphics/opengl.html:

so official 2.0 support might be a bit off :/
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Possibly, but it does still support it in the NDK(really, this hardcore graphics stuff should be done in the NDK anyway). Even there it's not really official, but they aren't likely to change the API calls since those are already set in stone by khronos.
[Nexus One Android Development] robert-qfh:
Hi Marcus,

to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:

build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so

It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.

Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:

LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2

If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday :D

I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Alright! Thanks for the help. I've done a lot of opengl work before and a little bit of opengl es when i had my g1 but haven't ever used the ndk, so that'll get me started.

EDIT: Sweet, I've dumped the list of functions available and it looks like all the appropriate shader functions are there. I'm attaching the full list output from my computer. I actually had to use arm-eabi-strings, since the objs one showed no objects. Regardless, it's looking good on the OpenGL ES2.0 front, and I've already looked into running opengl code from the NDK which is perfectly possible and ok.

ANOTHER EDIT: Haven't quite gotten it to build yet, but I got it to load gl2.h without any complaints. Now I just have a crapload of errors because the sample project I was using(from the ndk samples, san-angeles) was written for OpenGL ES 1.0 and all the things now done in shaders no longer exist(GL_LIGHTING, GL_MATERIAL, etc). Regardless, I'm considering this a success so far, since all that is expected.

YET ANOTHER EDIT: It runs! I'm not displaying anything yet(so it's not really a good test), but I got the shared library to build using OpenGL ES 2.0 and it runs on my phone. Gonna implement a simple program to display a triangle or something just to prove it works and will provide source code/binaries here(also, if anyone has a Droid or knows someone who does, it'd be great if we could test out to make sure this works on the Droid as well)
[Nexus One Android Development] pr0cl1v1ty:
I just wanted to drop in and say I'm very interested in what y'all are doing I'm of very good at coding. All I know is Java but ill definantly be following yall and keep up the good work
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Decided to post a reply, rather than just adding to that one post.

Well, I encountered a fairly large roadblock:

E/libEGL ( 3366): called unimplemented OpenGL ES API

That's what I see now every time I call one of the functions dealing with ES 2.0. I'm hoping there's another library I can use that'll make that go away, but we might not be as easy as I thought to do this.
[Nexus One Android Development] robert-qfh:
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...

I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Well I managed to view the assembly code, but can't get it into any form that I can/want to read(I know how to read assembly but unless you spend hours with it, it's damn near impossible to decode anything. Plus, I haven't looked at ARM assembly before). Know of a good program to convert it into C?

At any rate, I'll attach the disassembler dump(ran it using arm-eabi-objdump with flags -DS). From looking at it briefly, all the implemented functions look like they might be stubs since they're pretty bare bones and have almost all the same instructions(with a slight modification to one single instruction). But it's hard to tell with assembly. Let me know if you can make anything of it. I had to attach the file in a .zip by the way because it was too big.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
SUCCESS!!!! So, it looks like those functions were stubs. Google seems to have done it intentionally for whatever reason. They took the .so that actually worked(libGLESv2_adreno200.so) and shoved it under /system/lib/egl, which the ndk doesn't seem able to access(gives you a runtime error if you linked against it). However, If you just copy that file to /system/lib (yes, this requires root unfortunately) then you can use it. I successfully drew a triangle using shaders :D.

I'll try to get it to attach that xxx_adreno200.so file to the .apk so it can be used without messing around with such things(and work without root). If I can, then I'll throw it on here so everyone can see. Right now it's just a triangle, but tomorrow: the world.

EDIT: Alright, I attached the .apk(it's in the zip file, xda still doesn't allow posting .apks). I tried to attach the libGLESv2_adreno200.so library to it, so it wouldn't require moving the local one but it just wouldn't accept it. So, at least for the mean time, if you want to actually run that app without having it crash you'll have to do an adb remount and then the following in the terminal(or adb shell) as root:

cd /system/lib/egl
cp libGLESv2_adreno200.so ../

Once you do that, when you run the app it should display a yellowish triangle on a blue background(it was from the second tutorial from the OpenGL ES 2.0 sdk for PowerVX). Like I said, it's not much right now, but it is using custom shaders to display that triangle.

ANOTHER EDIT: I decided to change the test program a little. All I changed was the fragment and vertex shaders, which I made to change the color of the pixels based on where they are on the triangle. This should show(to those of you who know OpenGL) that it really is using custom shaders, since it's one triangle and it's clearly not using fixed-function pipeline shading ;).
[Nexus One Android Development] amokan:
Awesome work on reverse-engineering this! Keep us posted.
[Nexus One Android Development] conduct:
Indeed, keep at it Marcus! Very interested to see how this progresses.
[Nexus One Android Development] robert-qfh:
Well done, Marcus! I'm glad you found that working library.

You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:

gcc ... -Wl,-rpath=/system/lib/egl

That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.

I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Ya, I tried adding it to LOCAL_LDLIBS, but that just seemed to make it use that path for the local library on my computer when building it. It still failed to find that library on my phone when I ran it. I'll try poking around a little more since that would obviously be ideal.
[Nexus One Android Development] robert-qfh:
Alright. Are you sure you used rpath and not rpath-link?

BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
[Nexus One Android Development] MarcusMaximus04@gmail.com:
I didn't touch either actually, just changed the name of the library and the path it had. I haven't done a lot of make files beyond the most basic operations so a little study might be necessary.

Haven't tried the emulator image one, but the one from the phone just had those stubs. It would be really strange if the emulator had the actual functionality and the phone didn't.

I think you're right that if there's hope then it lies in the makefile, so I'll keep looking into that.

EDIT: Just tried adding --rpath=/system/lib/egl everywhere I could possibly think of and all with no change.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?

Ack, tried it, didn't do anything. Still can't find that library.

So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
[Nexus One Android Development] pr0cl1v1ty:
thats depressing :( i was checking this thread like 10 times a day waiting for new info to popup lol call me obsessed but i respect your work
[Nexus One Android Development] robert-qfh:
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this

LD_LIBRARY_PATH=/some/path /path/to/program

then the linker will search that path for libraries.

Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:

static {

// Set environment variable LD_LIBRARY_PATH

System.loadLibrary("your_jni_lib");

}

Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into :-)

EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Sure. I'll post it when I get home from work tonight. I don't have anything proprietary in there yet. :cool:

For the setting of the environment variable, from my understanding that's basically what System.SetProperty("java.library.path"... is supposed to do. But it still couldn't find the library and didn't seem to have any effect.

The dlopen bit might work. I was thinking of trying that but haven't had any time. I'm not really too sure on how these shared libraries are used, whether once they're open any other program can find and use them or whether the path to them has to be given explicitly at link time for the program that wants to use them and just generally having one loaded won't help.

EDIT: By the way, @pr0cl1v1ty: Don't worry, I'm not going to stop digging into ES 2.0 entirely. I'm just not going to be pushing as much for getting it to work on non-rooted phones. I've got bigger fish to fry.
[Nexus One Android Development] robert-qfh:
As far as I understand, the java.library.path property is used by the JVM to load native libraries, just like the JNI library we load with System.loadLibrary(jniLib). However, it does not map to the traditional UNIX environment variables, and therefore does not influence any native code, like the library loader, that's trying to find the dependencies of jniLib.

Modifying the UNIX environment of the process from Java code is not possible (stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java). You can read it using System.getenv(), but the map you get is read-only. A workaround might be to use a 2nd native library that modifies the environment using putenv(). But that's way too hackish for my taste, and we don't even know if the library loader will care about LD_LIBRARY_PATH or some other variable - after all, Google has optimized/stripped a lot of functionality we know from a desktop Linux.

Every Unix process that wants to use functionality of a shared library has to load it, either by using dlopen() or by embedding the information about required shared objects into the binary. In the latter case, the library loader will take care of loading the library and patching the addresses of the functions into the code. The OS doesn't really load the library into RAM multiple times if more than one process is using it, nevertheless every process has to load the shared library explicitly.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Ah, gotcha(with regards to the environment path). I agree that that does sound like a bit too much of a hack, especially since it'd be just a temporary fix until Google gets their act together.

Right. I think the problem we're having is that it is using the second method(embedding information about required shared objects into the binary) but it's trying to read from /system/lib and ignoring /system/lib/egl.

Argh, trying to change the LD_LIBRARY_PATH env variable so I can try this out but the damn thing is set up in /init.rc, which, as always, is read-only and can't be mounted read/write.

And setting the environment LD_LIBRARY_PATH doesn't appear to work either. From the terminal I did:

export LD_LIBRARY_PATH=/system/lib:/lib:/system/lib/egl
am start -a android.intent.action.MAIN -n com.example.SanAngeles/.DemoActivity

and it still said it couldn't find the library. So either running an activity like this restarts it with its own environment variables(possible, but I would think it would continue using the ones from the shell it was launched from), or the system doesn't bother looking at LD_LIBRARY_PATH at all.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
By the way, anyone know a place like this for the Droid? I figure they're in a similar boat ES2.0-wise and they might have some talented devs who could help figure this out. Plus, we could try to see if they have a similar library that works.
[Nexus One Android Development] pr0cl1v1ty:
Finally something I can help with. ;) ill go see if I can round up any devs
[Nexus One Android Development] robert-qfh:
FINALLY! I got a small OpenGL ES 2.0 sample program (based on webreference.com/programming/opengl_es/) running. The only output is a static red triangle, but it uses a vertex and a fragment shader :D

And the best thing: it's a locked, unrooted Nexus One. The important thing is to load the library at the right moment:

class DemoRenderer implements GLSurfaceView.Renderer {

public void onSurfaceCreated(GL10 gl, EGLConfig config) {

System.loadLibrary("glesv2sample");

nativeInit();

}

...

(code based on the SanAngeles sample)

By some mechanism (probably the initialization of the GLSurfaceView) the ES 2.0 libraries are loaded automatically, BEFORE the JNI lib is loaded, without us doing anything special to request 2.0 support. When the JNI lib gets loaded, the linker does not have to lookup the path of the library again.

All you need in Android.mk is

LOCAL_LDLIBS += -L/path/to/local/copy/of/glesv2/lib -lGLESv2_adreno200

No rpath necessary (I think it's being ignored), and no LD_LIBRARY_PATH modifications. Before I found this simple solution I tried the helper-library approach where putenv() is used to set the variable. I can modify environment variables this way, and the bionic linker actually parses this variable (verified that with the bionic source code) but it still didn't work. Doesn't matter now.

I wonder if Droid users have an OpenGL ES 2.0 library as well, where it's stored, and if its name is GLESv2_adreno200.so as well...
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Nice. I figured you might have better luck than me at doing that. Alright, so now we're pretty well good. I'm still working on porting that game, but I'll put up some free beta versions of it so everyone at xda can check it out. Also, everyone who posted so far on this thread is welcome to the final game if you want it. My thanks for everyone's help.

Oh and I found a droid owner. Turns out they have libGLESv2_POWERVR_SGX530_121.so. I'm wondering if theres a way to have it link with one or the other, depending which is available?
[Nexus One Android Development] robert-qfh:
That calls for using dlopen(), in a slightly different way than I sketched before:

Java code

-> System.loadLibrary('glesv2wrapper.so')

glesv2wrapper (NOT linked to any of the gles libs via -l)

-> dlopen('glesv2wrapper_nexus.so'), if that fails

-> dlopen('glesv2wrapper_droid.so')

glesv2wrapper_nexus.so links to libGLESv2_adreno200 via -l

glesv2wrapper_droid.so links to libGLESv2_POWERVR_SGX530_121 via -l

Both export a minimal set of functions, like initialize() and drawFrame().

The main wrapper (glesv2wrapper) uses dlsym() to get pointers to those functions and dispatches the calls from Java world to the device-specific library loaded before.

The downside is that both device specific libraries, even though they share the same source code, will basically be a copy of each other, the only difference being the GL library they're linked to.

Advantage is that you don't have to dlsym() every single gl....() function (as it would be the case if you dlopen()'ed the libGLESv2_* directly).

BTW, which game is it you're porting?
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Gah, ya was afraid of that. It might actually make sense to do it the second way, using dlsym on every gl function. That way one person would need to do it once and open source it and boom, everybody could just tie that in.

For the game, it's the same one I mentioned in the first post. Video of it here: http://www.youtube.com/watch?v=f7ovEbpOAn4

By the way, in case you're curious: I'm pretty well along in porting it. I have all the actual gameplay ported(except the controls, right now there's no way to control it) but don't have any of the display code moved over. Well, that's not completely true, I've ported over the main vertex shader that is run on pretty much everything except the smoke particles. But I still don't have any of the code implemented to actually use it. That main c drawing code is going to be a pain. C# isn't too much different from java so the main gameplay was easy enough. The Direct X shader language(forget what they call it) is also pretty similar to GLSL, so that hasn't been too bad either. But porting from C# using the XNA libraries to basic C using OpenGL ES 2.0? That's going to be intense. Luckily that drawing code isn't too involved and is mostly just setting up the uniforms for the shaders.
[Nexus One Android Development] xdarkfirex:
So in simple terms I can use ES 2.0 on the nexus and droid w/o rooting the phone to move over the libraries. If that is so, good work. This deserves some sort of news.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Indeed. Now to make it work on both the Droid and the N1.
[Nexus One Android Development] MarcusMaximus04@gmail.com:
Of interest, there doesn't appear to be any of the helper functions you get with the PowerVR(or at least I can't find them), so it looks like we're gonna have to do a lot of stuff on our own(like setting up perspective matrices... ewww)

And looks like texture loading is gonna be a bit intense as well... yay.