Android port

[fabio]

It is possible to sell it, but it is not possible to prevent people from freely redistributing it. So someone could buy it and then offer it for free to everyone else.

There are many ways to workaround this:

1. change the license to Android specific code to a non-free one, forbidding redistribution (obviously one can rewrite this code);
   
2. trademark "wildfiregames" or "0 A.D." and forbids its use on Android Market (the code is still free, but cannot be distributed as 0 A.D. (see Red Hat and its clones));
   
3. just link from the 0ad web page the sponsored 0 A.D. Android App, asking to buy it for supporting development rather than downloading it for free;
   
4. provide some plus service other than the game binary (let's suppose you can, for example, submit your game score to a central server comparing to other players...);
   

That being said what I like most about 0 A.D. is the fact it is free (according to the FSF) and for sure I wouldn't be interested in it otherwise, but anyway it would be nice if developers can find a way to sponsor its development.

[gameboy]

@abio: The program steps are too complicated, this game has always been free, and unnecessarily so. Thank you!

@Ykkrosh :The development of different resolution can be achieved according to each of the different resolutions of the mobile platform?

The game automatically adjusts the resolution, in different mobile devices? Such as: the Galaxy S II screen resolution is 800 * 480, if the game can automatically support it (the game can automatically adjust the resolution).

thank you!

Edited February 21, 2012 by gameboy

[evanssthomas]

Rough usage instructions:

"hg clone http://hg.libsdl.org/SDL" into build/android/sdl-project/jni/ (or clone elsewhere and symlink it there, or whatever). Until this bug is fixed, apply the patch from there.

In build/android/sdl-project/, run "make". That should compile SDL and the .apk file. (Dependency checking is probably broken, so run "make clean" if you need to rebuild after changing stuff.)

In build/android/, run "./setup-libs.sh". The script hardcodes the expected locations of NDK and SDK, so put them there or adjust the script, and it will output to ~/android/toolchain-0ad. That should download and compile loads of stuff.

Build the game like

./update-workspaces.sh --gles --android --without-fam --without-audio --disable-atlas --with-system-mozjs185 --with-system-enet --with-system-nvtt --without-nvtt

and

TOOLCHAIN=${HOME}/android/toolchain-0ad PKG_CONFIG_LIBDIR=${TOOLCHAIN}/sysroot/usr/local/lib/pkgconfig LDFLAGS="-lSDL2 -L=/usr/local/lib -L../../android/sdl-project/libs/armeabi" INCLUDES="--sysroot=${TOOLCHAIN}/sysroot -I${TOOLCHAIN}/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/ -I../../android/files/SDL/include -isystem=/usr/local/include/boost-1_45" CXX=${TOOLCHAIN}/bin/arm-linux-androideabi-g++ make pyrogenesis -j3 config=debug

Then attach a device, and in build/android/sdl-project/ run "make push-apk" and "make push-so". Run /sdcard/0ad.apk on the device to install. Then you need to build a public.zip containing all the data files, kind of like what source/tools/dist/build.sh does, and preferably unzip+zip it so that it's compressed properly (to save bandwidth and space), and push to /sdcard/0ad/data/mods/public/public.zip, then run the app.

Hi Philip,

I've followed the instructions as such and everything completed successfully except libpng where setup-libs.sh downloads libpng-1.5.8.tar.xz but tries to unpack libpng-1.5.7.tar.xz. I changed that in the setup-libs.sh script.

when I run make push-so, I get the following error. Apparently libpyrogenesis_dbg is not getting created. Any idea why?

cp ../../../binaries/system/libpyrogenesis_dbg.so libs/armeabi/
cp: cannot stat `../../../binaries/system/libpyrogenesis_dbg.so': No such file or directory
make: *** [push-so] Error 1

Great effort on the Android port, by the way!

Evans

[evanssthomas]

The build was actually not completing successfully. I somehow failed to notice that.

TOOLCHAIN=${HOME}/android/toolchain-0ad PKG_CONFIG_LIBDIR=${TOOLCHAIN}/sysroot/usr/local/lib/pkgconfig LDFLAGS="-lSDL2 -L=/usr/local/lib -L../../android/sdl-project/libs/armeabi" INCLUDES="--sysroot=${TOOLCHAIN}/sysroot -I${TOOLCHAIN}/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/ -I../../android/files/SDL/include -isystem=/usr/local/include/boost-1_45" CXX=${TOOLCHAIN}/bin/arm-linux-androideabi-g++ make pyrogenesis -j3 config=debug

In the above line, I had to change -I../../android/files/SDL/include to -I../../android/sdl-project/jni/SDL/include/ to get it to work.

Then you need to build a public.zip containing all the data files, kind of like what source/tools/dist/build.sh does, and preferably unzip+zip it so that it's compressed properly (to save bandwidth and space), and push to /sdcard/0ad/data/mods/public/public.zip, then run the app.

Zipping up the contents of ~/0ad/binaries/data/mods/public and pushing it to my SD card did not work. If you could let me know specifically what files need to be in the zip file, that would be great.

Thanks

Edited February 25, 2012 by evanssthomas

[Ykkrosh]

I've followed the instructions as such and everything completed successfully except libpng where setup-libs.sh downloads libpng-1.5.8.tar.xz but tries to unpack libpng-1.5.7.tar.xz.

Oops, fixed now. (Also I slightly cleaned up and committed some earlier changes that I'd used to get the game launching, though I haven't tested the current code on Android yet.)

Zipping up the contents of ~/0ad/binaries/data/mods/public and pushing it to my SD card did not work. If you could let me know specifically what files need to be in the zip file, that would be great.

You need to use the game engine to create the zip, since it has to convert all the textures/models/animations/etc into a different format before zipping them up. Build a standard non-Android copy of the game, then run like "binaries/system/pyrogenesis -archivebuild=binaries/data/mods/public -archivebuild-output=temp/public.zip" and it should print lots of output and will take a while (maybe ten minutes or more). Then (optionally) extract that ~700MB public.zip into a new directory and zip it all up again so that it's properly compressed to ~300MB. Then copy to /sdcard/0ad/data/mods/public/public.zip and the game should see it. (If you want to change a few data files after that, you don't need to regenerate public.zip - just copy the individual files straight into mods/public/ and they'll override the zipped version.)

Also, copy binaries/data/config/default.cfg into /sdcard/0ad/appdata/config/.

Hopefully that's about enough, but I might be forgetting things. The game's log messages are visible through "adb logcat" so that should indicate when things are going wrong.

[WhiteTreePaladin]

@Evans,

Haven't seen you in a while. Nice to see that you still visit.

[WhiteTreePaladin]

Then copy to /sdcard/0ad/data/mods/public/public.zip and the game should see it.

By the way, I noticed a significant speed improvement when reading PDF files by simply moving them off the SD card to internal storage. Depending on the class of SD card you are using, this will likely hold true.

[gameboy]

This looks a lot of trouble to compile another better way? More simple methods of compiling, thank you!

@historic_bruno's :The development of different resolution can be achieved according to each of the different resolutions of the mobile platform?

The game automatically adjusts the resolution, in different mobile devices? Such as: the Galaxy S II screen resolution is 800 * 480, if the game can automatically support it (the game can automatically adjust the resolution).

thank you

Edited February 26, 2012 by gameboy

[Ykkrosh]

By the way, I noticed a significant speed improvement when reading PDF files by simply moving them off the SD card to internal storage. Depending on the class of SD card you are using, this will likely hold true.

As far as I'm aware, /sdcard is not an SD card - it's just a partition of the standard built-in Flash storage. (The SGS2 apparently has 16GB of storage, split into ~2GiB of "device memory" for applications, 11.5GiB of "USB storage" for data or large applications, and presumably ~2GiB for system stuff). (The optional external SD card gets mounted into /sdcard/external_sd instead). So I think in theory it shouldn't make a difference on this device, though I've never tested it. Since loading performance isn't too bad anyway (and I'd suspect it's mostly CPU-bound), and the "device memory" is pretty small, and it's hard to upload/download files to device memory (I think the only way is 'adb push' to /data/data/local/, and the USB connection is much slower than copying with SFTP over wifi), it doesn't seem worth the effort to me

This looks a lot of trouble to compile another better way? More simple methods of compiling, thank you!

This is an experimental prototype for developers - if you don't understand the instructions, it's probably not for you

[Ykkrosh]

(Also I slightly cleaned up and committed some earlier changes [...])

Oh, forgot to mention that I also changed the script to use r7-crystax-5.beta2, which fixes the HTTP-based profiler (r7-crystax-4 overrides the standard socket functions and then doesn't actually implement select() so everything breaks confusingly). If you don't care about the profiler then changing it back to the earlier NDK version should work.

[gameboy]

The development of different resolution can be achieved according to each of the different resolutions of the mobile platform?

The game automatically adjusts the resolution, in different mobile devices? Such as: the Galaxy S II screen resolution is 800 * 480, if the game can automatically support it (the game can automatically adjust the resolution).

thank you

[evanssthomas]

I built public.zip, updated the source code and rebuilt it - tried everything you said, but still couldn't get it to work. Logcat doesn't seem to give much useful info other than that it crashed. I've attached the logs but I'm not sure if it will be of much use. I'm running it on a Samsung Galaxy R which has processing power comparable to the SGS2 (With a different processor family, though).

@Brian - Good to know that you remember! Yeah, I regularly follow development and always have my source code up to date Really wish I could still contribute, but don't find time to do it. Work it hectic as it is. The Android port will probably help provide the motivation I need to find time to start contributing again (I'm really into Android these days).

log.txt

[Ykkrosh]

That says:

I/DEBUG   (21117): Build fingerprint: 'samsung/GT-I9103/GT-I9103:2.3.5/GINGERBREAD/XWKI5:user/release-keys'
I/DEBUG   (21117): pid: 22328, tid: 22337  >>> org.libsdl.app <<<
I/DEBUG   (21117): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 823ed560
I/DEBUG   (21117):  r0 00082c20  r1 00000000  r2 00000001  r3 82c20e28
I/DEBUG   (21117):  r4 82c002ac  r5 0000010f  r6 00000004  r7 480e89c8
I/DEBUG   (21117):  r8 480e8b40  r9 40086fb8  10 40086fa4  fp 802a5374
I/DEBUG   (21117):  ip 82c00390  sp 480e89c8  lr 823ed4e7  pc 823ed560  cpsr 20000030
[...]
I/DEBUG   (21117):          #00  pc 003ed560  /data/local/libpyrogenesis_dbg.so
I/DEBUG   (21117):          #01  lr 823ed4e7  /data/local/libpyrogenesis_dbg.so
I/DEBUG   (21117): 
I/DEBUG   (21117): code around pc:
I/DEBUG   (21117): 823ed540 00001608 b085b590 4c2aaf00 6078447c 
I/DEBUG   (21117): 823ed550 58e34b29 60fb681b eeff687b edc30b00 
I/DEBUG   (21117): 823ed560 687b0b10 0200f04f 687b60da 0200f04f 
I/DEBUG   (21117): 823ed570 687b611a 0200f04f 687b615a 4b1f681a 
I/DEBUG   (21117): 823ed580 681b447b 46194610 e18ef20d 46184603
[...]
I/DEBUG   (21117): stack:
[...]
I/DEBUG   (21117): #00 480e89c8  00000004  
[...]
I/DEBUG   (21117):     480e89e4  823ed4e7  /data/local/libpyrogenesis_dbg.so
[...]
I/DEBUG   (21117):     480e8a0c  823ef25f  /data/local/libpyrogenesis_dbg.so

so to (hopefully) see where it's failing, run

~/android/toolchain-0ad/bin/arm-linux-androideabi-addr2line -e binaries/system/libpyrogenesis_dbg.so 003ed560
~/android/toolchain-0ad/bin/arm-linux-androideabi-addr2line -e binaries/system/libpyrogenesis_dbg.so 003ed4e7
~/android/toolchain-0ad/bin/arm-linux-androideabi-addr2line -e binaries/system/libpyrogenesis_dbg.so 003ef25f

(pc is current function, lr is caller, and any line after #00 in the stack that's labelled with the .so name is probably part of the call stack. You need to mask off the leading "82" in the addresses because the code was relocated at runtime, I think.)

Since this is an ILL_ILLOPC (illegal opcode), I think it's most likely due to differences in CPU. Galaxy R apparently uses Tegra 2, which is Cortex-A9 (like Galaxy S2) but without NEON (unlike Galaxy S2), and the game is compiled to assume NEON support. Try editing build/premake/premake4.lua and remove the "-mfpu=neon", and also edit build/android/setup-libs.sh to remove the "-mfpu=neon", then clean and rebuild everything, and it might be happier.

(In particular, the instruction just before the pc (i.e. the one whose execution triggered the exception, if I understand this correctly) is "edc30b00", which is "vstr d16, [r3, #64]" and therefore requires NEON support, so that seems a plausible explanation. Edit: Oops, I keep getting confused by endianness. The vstr is actually "edc3 0b10", and the problem is more likely the earlier "eeff 0b00 fconstd d16, #240" starting at 823ed55a, though I don't understand quite how the reported pc value (6 bytes later) relates to that.)

[evanssthomas]

Thanks a ton for your help Philip, but it still isn't working

Now I'm getting a different error:

I/DEBUG   (26951): Build fingerprint: 'samsung/GT-I9103/GT-I9103:2.3.5/GINGERBREAD/XWKI5:user/release-keys'
I/DEBUG   (26951): pid: 27139, tid: 27148  >>> org.libsdl.app <<<
I/DEBUG   (26951): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG   (26951):  r0 00000027  r1 deadbaad  r2 80000000  r3 00000000
I/DEBUG   (26951):  r4 00000001  r5 00000000  r6 00000001  r7 afd42718
I/DEBUG   (26951):  r8 48109b40  r9 442b9fb8  10 442b9fa4  fp 802a5374
I/DEBUG   (26951):  ip afd466c8  sp 48108910  lr afd19711  pc afd161e0  cpsr 60000030
I/DEBUG   (26951):  d0  3f80000000000000  d1  40dfae1400000000
I/DEBUG   (26951):  d2  be5acaf22c836220  d3  4014000000000000
I/DEBUG   (26951):  d4  3fe00000001ec5bd  d5  4187e02ec0000000
I/DEBUG   (26951):  d6  4000668b9fdbd2fa  d7  4000668b9fdbd2fa
I/DEBUG   (26951):  d8  0000000000000000  d9  0000000000000000
I/DEBUG   (26951):  d10 0000000000000000  d11 0000000000000000
I/DEBUG   (26951):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   (26951):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   (26951):  scr 20000010
I/DEBUG   (26951): 
I/DEBUG   (26951):          #00  pc 000161e0  /system/lib/libc.so
I/DEBUG   (26951):          #01  lr afd19711  /system/lib/libc.so
I/DEBUG   (26951): 
I/DEBUG   (26951): code around pc:
I/DEBUG   (26951): afd161c0 2c006824 e028d1fb b13368db c064f8df 
I/DEBUG   (26951): afd161d0 44fc2401 4000f8cc 49124798 25002027 
I/DEBUG   (26951): afd161e0 f7f57008 2106ea16 eb8af7f6 460aa901 
I/DEBUG   (26951): afd161f0 f04f2006 95015380 95029303 eef0f7f5 
I/DEBUG   (26951): afd16200 462aa905 f7f52002 f7f5eefc 2106ea02 
I/DEBUG   (26951): 
I/DEBUG   (26951): code around lr:
I/DEBUG   (26951): afd196f0 4a0e4b0d e92d447b 589c41f0 26004680 
I/DEBUG   (26951): afd19700 686768a5 f9b5e006 b113300c 47c04628 
I/DEBUG   (26951): afd19710 35544306 37fff117 6824d5f5 d1ef2c00 
I/DEBUG   (26951): afd19720 e8bd4630 bf0081f0 00027e6c ffffff88 
I/DEBUG   (26951): afd19730 b086b570 f602fb01 9004460c a804a901 
I/DEBUG   (26951): 
I/DEBUG   (26951): stack:
I/DEBUG   (26951):     481088d0  afd426c4  
I/DEBUG   (26951):     481088d4  000a5d40  
I/DEBUG   (26951):     481088d8  0000002b  
I/DEBUG   (26951):     481088dc  afd187d9  /system/lib/libc.so
I/DEBUG   (26951):     481088e0  afd42664  
I/DEBUG   (26951):     481088e4  afd46838  
I/DEBUG   (26951):     481088e8  00000000  
I/DEBUG   (26951):     481088ec  afd19711  /system/lib/libc.so
I/DEBUG   (26951):     481088f0  00000001  
I/DEBUG   (26951):     481088f4  48108924  
I/DEBUG   (26951):     481088f8  00000001  
I/DEBUG   (26951):     481088fc  afd42718  
I/DEBUG   (26951):     48108900  48109b40  
I/DEBUG   (26951):     48108904  afd18a33  /system/lib/libc.so
I/DEBUG   (26951):     48108908  df002777  
I/DEBUG   (26951):     4810890c  e3a070ad  
I/DEBUG   (26951): #00 48108910  00000001  
I/DEBUG   (26951):     48108914  afd18825  /system/lib/libc.so
I/DEBUG   (26951):     48108918  0000000a  
I/DEBUG   (26951):     4810891c  afd1cd37  /system/lib/libc.so
I/DEBUG   (26951):     48108920  afd42670  
I/DEBUG   (26951):     48108924  fffffbdf  
I/DEBUG   (26951):     48108928  442b9fb8  
I/DEBUG   (26951):     4810892c  afd42670  
I/DEBUG   (26951):     48108930  82a6cdc4  /data/local/libpyrogenesis_dbg.so
I/DEBUG   (26951):     48108934  813a58c8  /data/data/org.libsdl.app/lib/libSDL2.so
I/DEBUG   (26951):     48108938  00493530  
I/DEBUG   (26951):     4810893c  00000000  
I/DEBUG   (26951):     48108940  00493588  
I/DEBUG   (26951):     48108944  00493530  
I/DEBUG   (26951):     48108948  82c002ac  
I/DEBUG   (26951):     4810894c  00493588  
I/DEBUG   (26951):     48108950  48108980  
I/DEBUG   (26951):     48108954  813a4dc8  /data/data/org.libsdl.app/lib/libSDL2.so

[Ykkrosh]

It might be useful to know the lines logged by the engine before it crashes - it's possible that it's reporting an error and then abort()ing. Otherwise, addr2line might help - give it libpyrogenesis_dbg.so and address "00a6cdc4" (from the stack), and also get a copy of your /system/lib/libc.so (I think "adb pull" should be able to do that) and run addr2line with libc.so and maybe addresses "000161e0" and "00019711" and "00018a33" and "00018825" and "0001cd37".

[gameboy]

We need a good version of the Android 0 AD will be when completed it?

[ribez]

We need a good version of the Android 0 AD will be when completed it?

http://www.wildfiregames.com/forum/index.php?showtopic=15436&view=findpost&p=234288

[evanssthomas]

It might be useful to know the lines logged by the engine before it crashes - it's possible that it's reporting an error and then abort()ing. Otherwise, addr2line might help - give it libpyrogenesis_dbg.so and address "00a6cdc4" (from the stack), and also get a copy of your /system/lib/libc.so (I think "adb pull" should be able to do that) and run addr2line with libc.so and maybe addresses "000161e0" and "00019711" and "00018a33" and "00018825" and "0001cd37".

I haven't had a chance to try it out. I'll let you know when I get time to check it out.

Thanks!

[Pickle]

Hi ive had my eye on this project for a while, but never jumped into it because the system requirements. But seeing what has progessed on the android has caught my attention.

I would like to try to give the work on the andriod version a try on the pandora (a portable linux based handheld). It has very similar hardware to some mobile phones.

My version has 256 mb ram (current builds will have 512 mb ram). It supports GLES2.

Pandora would certainly be ideal mobile device given that it has superior controls to anything out there. Meaning touchscreen, qwerty keyboard, game buttons, analog nubs.

What I would like to know is at what point in the svn i should target, i.e. is the latest stuff in the trunk or on some branch.

Reviewing this thread i saw talk about both SDL 1.2 and SDL 1.3, which is needed? Pandora can support either, although I would need to see if the latest SDL 1.3 state is in.

Are there any special things I should do for data? I saw some talk about precalced models and stuff.

[Ykkrosh]

There are no branches, so you should use the latest SVN trunk code. SDL 1.3 got renamed to 2.0, and 1.2 doesn't support touchscreens, so you should use 2.0. For data, you should do the archivebuild thing from #155. This whole Android support is pretty rough so it probably won't work trivially, but hopefully it'll be possible to get something running

[Pickle]

There are no branches, so you should use the latest SVN trunk code. SDL 1.3 got renamed to 2.0, and 1.2 doesn't support touchscreens, so you should use 2.0. For data, you should do the archivebuild thing from #155. This whole Android support is pretty rough so it probably won't work trivially, but hopefully it'll be possible to get something running

Trunk it is then ;-)

Pandora's touchsreen is accessed through tslib (X input might be inbetween) which SDL 1.2 recognizes as absolute mouse input. Our SDL 2 port( 1.3 at the time) is missing control support last i tried. But I can start with either for video at least. Are both SDL versions supported?

I will be sure to let you know how it goes once I have some time to start working on it. Thanks for the pointers.

Edit: One other thing i wanted to mention, i saw some comments about needed to convert OpenAL, are you aware of the OpenAL-Soft project?

http://kcat.strangesoft.net/openal.html

This should be able to support any openAL funationality 0 ad uses.

Edited March 16, 2012 by Pickle

[Ykkrosh]

The game should build fine with 1.2 or recent 1.3/2.0 (we use 1.2 on standard desktop Linux).

We run with OpenAL-Soft on Windows, so it does support what we need, but I don't think anyone has seriously examined audio support for Android yet, so I don't know if that'd be a good solution or not. Probably worth looking into.

[Scrivener]

Hey folks,

First post here, and I have no real coding experience (some Python, Ruby, Bash for sysadmin work), but the prospect of an Android port appeals to me greatly. Once I'm home with a little free time, I'll try to build it on my Asus Transformer Prime and get back to you. I figured, if nothing else, I could offer services and a modern Android device for development/alpha testing and documentation! And I'll probably learn a lot along the way.

I have more to read about the research you guys did into gesture controls (I haven't completely read the whole thread yet), but have a few ideas for intuitive navigation of the interface, and would also be interested in seeing keyboard/mouse controls available for those of us with Transformers Tablets In Disguise

As a suggestion on how to make money with the release, you don't need to close the source, sell based on branding, or any other such thing. Try just making the first fully functional .apk of the game available through a Humble Bundle release. Humble Bundle has already done 2 successful Android-specific bundles, and something as impressive as a fully completed 0ad port to Android would be a sure draw. Release it later either by your own means as a pay-what-you-want, or free on the Android market with a donation version available. We open source folks are generous! Test us!

[mpatton]

Hi all,

I wanted to test out some mods ive made to 0a.d. on andriod... Is there steps to compiling 0a.d. for andriod on windows or is it only setup for linux @ this stage?

thnaks in advance

Michael

[Ykkrosh]

Building for Android will only ever be possible on Linux. (I updated the instructions here recently to use the various build scripts that I added some time ago, but it's still far from step-by-step instructions and is only suitable for people who are comfortable with debugging the build process and code themselves.)