State of the Android port (1.5-2.1)

Delu · Post by **Delu** » Sat Mar 27, 2010 9:57 am

Hello,

is there any update on the Android port also in terms of making it official and available for Android 2.0/2.1 or some of it's technical background in terms of features like filters and stuff? There hasn't been an update on gus's page for a while.

I'm using the 1.5 app on my i5700 Spica fine so far but I want to update to the recently released 2.1 Android in the near future and of course I'd love to be able to continue using ScummVM with all of my favourite games.

Best regards and thx to gus for his work on the port so far and everyone else on the ScummVM Team!

Delu

fingolfin · Post by **fingolfin** » Sat Mar 27, 2010 7:05 pm

No news from the ScummVM team on this, it's all up to gus.

gus · Post by **gus** » Sat Mar 27, 2010 10:54 pm

Ok, so I've put together a whole new Android NDK toolchain based on the Openembedded build system - currently only published here:
http://github.com/anguslees/openembedded-android

Using this toolchain, ./configure works and the build hacks all go away which removes the big blocker to merging. So I just have to rebase my patches on ScummVM trunk (instead of the 1.0 branch) and we should be good to go.

In another development branch, I have rewritten all the graphics to use OpenGLES rather than unpublished Android internal 2D graphics libraries that keep changing ABI between Android releases. I had this running on Android 2.0+ (and hopefully cyanogenmod again) just 2 days ago but it still has a few glitches (mouse cursor keycolor isn't working, etc). I also went for "portable" rather than "fast" OpenGLES choices, so it could be made much faster by using some newer GLES extensions.

More worryingly, there seems to be a change in Android 2.0 that breaks resolving symbols between dlopened libraries - necessary for the ScummVM plugins to work on Android. I haven't investigated this at all yet, and the fix may be as simple as some different compiler options.

So: lots of progress, but none of it is ready for a new release candidate just yet.

Delu · Post by **Delu** » Sun Mar 28, 2010 10:50 am

Heya gus,

although I'm not familiar with the actual coding or any at all I can just guess but it sure sounds exciting, like much effort and indeed lots of progress

Thx for the update and maybe someone else could help out with some of the stuff you mentioned above.

Best Regards
Delu

singalen · Post by **singalen** » Mon Mar 29, 2010 4:09 pm

Can you pretty please publish the binary?

And, may I ask for a hint to some basic tutorial for building on openembedded?

Thank you!

gus · Post by **gus** » Mon Mar 29, 2010 11:35 pm

singalen wrote:Can you pretty please publish the binary?

The one that doesn't work yet?

I stashed a copy of my latest compile output as "scummvm-2.0alpha.apk" on here: http://sites.google.com/site/scummvmandroid/dev/

singalen wrote:And, may I ask for a hint to some basic tutorial for building on openembedded?

I just put together this: http://wiki.github.com/anguslees/openembedded-android/
Let me know if any of that needs further explanation.

singalen · Post by **singalen** » Thu Apr 01, 2010 10:27 pm

gus wrote:The one that doesn't work yet?

I stashed a copy of my latest compile output as "scummvm-2.0alpha.apk" on here:

Ah, thank you.
I hoped it had worked at least some way - if the transition didn't require complete switch to another API.

gus wrote:I just put together this: http://wiki.github.com/anguslees/openembedded-android/
Let me know if any of that needs further explanation.

That's pretty clear, now building toolchain. Just needed a kick to start.

At least, I can do some dumb work like porting the patch. Is it necessary, or you plan to use OpenGLES only?

May I ask you another dumb question - what's the point of not using Android NDK? Are there any problems using its arm-eabi-g++ and everything to build ScummVm?

I seem to randomly google to couple of known bugs in Android with dlopen(). Though, I really don't know is it what you encountered.
Discussion one, discussion two, bug 599, bug 2042

If someone tries this too, FYI:
* On Ubuntu 9.10, I had to install bitbake-1.8.18, as 1.8.12 crashed with errors like "NameError: global name 'os' is not defined". Looks this is a known bitbake bug, I registered an update request for Ubuntu.
After installing it by hand, I had to set PYTHONPATH to its lib dir.
* I also had to "dpkg-reconfigure dash" and answer "No".
* openembedded's sanity check requests to install several utilities. I needed: apt-get install help2man diffstat texi2html texinfo cvs

Ah, configure --help doesn't mention Android as --backend and --host.

Delu · Post by **Delu** » Wed Apr 07, 2010 4:59 pm

So how is it going? Also I've read the new scummvm release adds 16 bit support, wasn't that somehow already in your port?

singalen · Post by **singalen** » Fri Apr 09, 2010 12:11 pm

Delu wrote:So how is it going? Also I've read the new scummvm release adds 16 bit support, wasn't that somehow already in your port?

I was going to port the patch to trunk, but failed to get the toolchain: needed to get more of hard drive.

Now making a second attempt.
Didn't come to building scummvm4android yet, but here is the SDK I compiled:
http://victorsergienko.com/files/androi ... id.tar.bz2
http://victorsergienko.com/files/androi ... as.tar.bz2
http://victorsergienko.com/files/androi ... 5te/ipk.7z

singalen · Post by **singalen** » Sat Apr 10, 2010 11:41 pm

I still don't know enough to compile scummvm with openembedded. Looks like I need some bitbake conf files. Will study more.

I did some dumb mechanical porting of the patch to trunk. Here it is:
http://victorsergienko.com/files/scummv ... .patch.bz2
Though I have problems:
1. Some pieces of Android confguration seem to be already in.
2. I can't test building it for Android yet, and even for Linux it fails with an error: "/home/user/src/android/rel1.5/build/core/version_defaults.mk: No such file or directory". Will look into it later.

gus, some sort of further build instruction could help your followers

For instance, ANDROID_SDK variable in ports.mk needs some mentioning.

Thank you

fingolfin · Post by **fingolfin** » Sat Apr 10, 2010 11:46 pm

And it still would be really, really nice to get this port official. Right now, it seems to be a matter of chasing tails. Gus works hard on updating the port, once that is done, we (well, he

can work on improving it, but !wham!, before it is done something new happens and Gus has to fix that, before he can return to clean up the new mess, etc., rince and repeat... Sad... Anyway, still hoping to see this become official. We could probably even provide daily builds via our buildbot etc.

All in all, I guess some extra man power would be good for the port

.

gus · Post by **gus** » Mon Apr 12, 2010 12:21 am

fingolfin wrote:And it still would be really, really nice to get this port official.

Totally.

singalen: the custom NDK is to try to make merging with ScummVM easier/possible. The current patch (in ScummVM bug tracker) includes some ugly hacks to ports.mk, which make it unacceptable for merging (like overriding the compiler used!).

The Google NDK's arm-eabi-gcc can't compile anything without a required set of command line flags, which makes it impossible to use with the ScummVM configure script. In order to build with arm-eabi-gcc, you need to hack something up to get configure to run, and then undo your hacks to actually build something correctly (hence the ports.mk overrides in the current patch). With a proper arm-android-eabi-gcc toolchain (like my openembedded one, or any of the ones that other people have put together), this goes away and all becomes sweetness and light.

I got suckered into trying to get something to work on Android 2.0 again, which I said I wouldn't do. Instead I'll just port the current crap to ScummVM trunk and work on getting it merged. Then *we* can work on making it cleaner.

Fwiw, I've concluded that OpenGLES sucks for ScummVM's needs (in particular, afaics it's impossible to incrementally update a texture in a way that supports pitch/stride). I'm going to chuck the last few months of work and go back to the simple Android 2D stuff.

fingolfin · Post by **fingolfin** » Mon Apr 12, 2010 12:01 pm

gus, if overriding the compiler and specifying special flags for using it is the only problem, we can certainly accommodate that in the current system without the need of a totally new tool chain, hopefully even without too much work.

Several ports have this requirement, in fact, at least for cross compiling. On our buildbot, for example, we typically invoke ScummVM's configure with something like this:

CXX=arm-eabi-gcc \
CXXFLAGS="-isystem /opt/MyCoolSDK/include -fancy-special-compiler-option \
LDFLAGS="-L/opt/MyCoolSDK/lib -fancy-linker-flag" \
./configure --enable-all-engines

This is not pretty, but works, and if this allows us to get the source quicker to SVN, I'd recommend using it (this invocation could even be put into a simple shell script in backends/platforms/android/). A better solution via support code in the configure script is of course nicer on the long run; but this approach sure beats having the whole port source in a separate tree, I think

.

Once again, I'll be happy to try and assist you with this. I don't have an Android phone, nor do I currently have the Android SDK/NDK/whatever setup on my machine (can I do that on OS X?), but at least I know ScummVM pretty well, and working on our Buildbot have some experience with cross compiler setups. So I am quite hopefully we can get that done.

fingolfin · Post by **fingolfin** » Mon Apr 12, 2010 12:02 pm

As for OpenGL ES: We are participating in Google's Summer of Code 2010, and some of the students have proposals revolving around writing OpenGL (ES and plain) code that can be reused between backends. This would, in theory at least, be then usable for the SDL, iPhone, Android, etc. ports.

Warzone · Post by **Warzone** » Thu Apr 15, 2010 3:43 am

Yep, indeed...the SDK is available for Mac OS X

http://developer.android.com/sdk/index.html

http://developer.android.com/guide/deve ... lator.html