VCMI for Android

Maybe a long shot, but dailies for android build?

This is one of two reasons why we need CI. Since we now have plenty space to host them there will be at least builds for Windows and OSX from Travis.

Okaaay, so after reading a bit about travis, I added an experimental config to lint.travis-ci.org/vcmi/vcmi-android says it’s syntactically valid, but I can’t really check anything more).
travis-ci.org/vcmi/vcmi-android says that travis is not enabled for this repo so I think you need to turn it on manually to check?

Btw, android app on master should compile/work correctly on android 4.1+.

I`ve enabled travis for "vcmi-android ". Next commit there should trigger build.

Okay, I tinkered with it for some time, but have to give up for today.
I think I’m past “obvious” errors already, because travis starts actual cmake build. Hopefully not much left until it builds correctly, because there errors are killing me. :stuck_out_tongue:

Might be will be able to check whats wrong in few days.
If build starts then dependency hell shouldnt be so much of a problem.

I’ll probably be able to continue working on it tomorrow. But if it’s still broken after few days, you’ll be welcome to help. :wink:

Build passed. I can’t really verify atm if everything is correct, but at least it finished and is all green now. :wink:

Great! Once I fix urgent “let’s remove user home directory” bug I’ll try to setup deploy from Travis to our new daily build server. :slight_smile:

Okay, I managed to detect the data path from previous version and migrate Data, Mp3, Saves and Maps folders and config/settings.json file. I decided to skip Mods folder though (I think it could cause problems aaand it would take more time to implement).

Edit ~ actually, the saves probably aren’t even compatible with current version, so probably they shouldn’t get migrated…

Feel free to mess with the travis file. :wink:
If you need it, generated artifacts should be in ./project/vcmi-app/build/outputs/apk/*.apk

There are still some (minor) things to solve for daily builds. Currently travis builds only one configuration (debug, api16+, armeabi-v7a). I think that ideally 2 packages should be created (release,api16,armeabi-v7a and release,api21,all abis). Changing the build to 2 packages is probably a matter of fiddling with travis config (+ less hardcoding in ./travis-extras/vcmiconf.json.in) and to build release package, we would need to add some “fake” signing to repo.

Two question regarding Android build. First of all I want to start use std::atomic. Is it working fine with NDK?

Also there is scary comment about NO_STD_TOSTRING. I see replacement provided enough convert unsigned short int to std::string, but what about other types? I suppose we shouldn’t use it right?

It’s hard to say exactly what works correctly and what doesn’t. Atomic should work, I used it for client/server synchronization.

More explanation about ndk features was in the PR for vcmi android support: github.com/vcmi/vcmi/pull/299/f … 499d876728 .
Full support of standard lib in ndk should come “soon”. E.g. according to github.com/android-ndk/ndk/issues/82 this is in development and currently planed for ndk r16 (which, I think, should be available in july).

I’m not sure what you mean. The replacement should handle everything that can be put into stringstream.

I tried to setup deploy for Android build, but for some weird reason It’s not appear in my Travis account. Might be something wrong with my permissions, but I’m not sure. Also there few question related to Travis build and Android.

First of all what the deal with all those dependencies in repository? Is there way to download them from somewhere? If no and you pre-built them from scratch we could instead put them on our server and setup caching on Travis. Tell me and I’ll give you SFTP account to upload them.

Another thing is APK naming. Travis allow to make builds by “cron” so my plan now is to use this feature so new Android builds from develop are created daily or at least when there are changes in develop. Though we also want to have builds when you change actual APK structure so I suggest that would be cool if you generate package name similar to what I did in develop and then store it in some environment variable, e.g like:

VCMI-{LAUNCHER_COMMIT}-develop-{DEVELOP_COMMIT}.apk

So there will be a way to add simple SFTP upload afterwards.

And one more question: xyz originally didn’t implement Qt launcher into package. Is there some reasons you didn’t try to adopt it too?

Since it’s you one maintain the code it’s perfectly fine, but I still wonder what technical difficulties is there to use Qt application for that. I suppose launcher UI completely incompatible with phones, but that’s not problem and can be rewritten. Mainly interested in this because I want to change mod distribution model and I wish we had one solution for all platforms.

What dependencies?

  • FFMPEG/iconv are added as submodules, (additionally, binaries added to repo in ext-output folder)
  • SDL2 is a submodule pointing to my fork of SDL (that has changes that allow resolving touches as left/right click correctly; also available as a binary in main project repo),
  • SDL2 addons need to be added manually (because SDL uses hg instead of git if I remember correctly) – also precompiled in the repo
  • boost needs to be added manually (I guess we could add it as a submodule from github.com/urho3d/android-ndk.git – currently I use this repo in travis build)
    Can’t think of any other dependencies.

Should be possible. Not sure if it can be automated from inside the gradle build but I definitely can make a script that passes hashes from git to gradle build script (hash is already included in app (saved in generated java file during cmake)).

To be honest, I didn’t check if it’s possible and went for “normal simple android app” route. It seems that qt does support android ( doc.qt.io/qt-5/android-support.html ).
I’m not sure if it’s possible to easily do qt+java app (android SDL port uses java).

It’s exactly what I’m talking about. Is there reason you can’t just download them within build process?
GitHub have 1GB soft limit and your repo already 168MB and it’s just bad practice to store binaries in git.

So would be better if Travis would just download them from our server (if there no other way to get them) during build process. Then we can rewrite repository history with rebase so it’s won’t be 160MB. :wink:

If you can implement it to generate package with name like that it’s would be great:

${TRAVIS_JOB_ID}-vcmi-${LAUNCHER_COMMIT}-develop-${DEVELOP_COMMIT}.apk

Once I find out why I can’t access encryption key on Travis for vcmi-android I’ll setup artifact uploading.

Thanks. It’s what I wanted to know.

Yeah, SDL addons would need to be either hosted somewhere and downloaded during build or mirrored on github and added as submodules.
Other than that, “./build.py fixpaths build-optional” should build all of the non-cmake libs.

I added them to repo because it makes building the project much simpler/quicker and these libs don’t really need to be ever rebuilt unless we upgrade lib versions.

Keep in mind that ffmpeg takes quite a long time to build (around 20 mins per arch on my pc) + it needs to be checked if travis machines can handle asm out of the box (yasm).

I should be able to do it tomorrow.

Yep I understand why you added them to the when you tried to get it work. This is just something that need to be changed and if there are no “ready to use” binaries available in trusted source then we can just host our own, but certainly not on git.

If you can please generate SSH key and send me public part so I can provide you with SFTP access to special server where you’ll able to upload all dependencies needed. :wink:

Current repo version of launcher should create output apks with name [travis_job_id]-[launcher_git_sha]-vcmi-[vcmi_branch]-[vcmi_git_sha]-debug].apk. ("-debug" only in debug builds, travis job id only if there’s such env variable, git-shas are first 7 chars).

Thanks. Is there any reason you want to stick to certain VCMI commit? Can’t you just build latest develop?

Asking since main reason to have Travis at all is to make sure we do not break building on Android.
Also I want Android builds to be generated and uploaded daily by Travis even when you’re away.