VCMI for Android

International board Development
#241

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.

#242

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.

#243

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).

#244

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.

#245

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.

#246

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:

#247

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).

#248

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.

#249

Do I? No idea. :stuck_out_tongue:
.gitmodules just specifies develop branch, not specific commit.

#250

Oops, I certainly misunderstand reason for commit hash in GeneratedVersion.java.
Might be you can later just add current commit there.

#251

Ok I uploaded test branch there, but I still want to get rid of those “committed with” messages. :imp:

PS: It’s looks like build works fine. :slight_smile:

/home/travis/build/vcmi/vcmi-android/project/vcmi-app/build/outputs/apk/243458287-vcmi-7609a0d-HEAD-fa02900-debug.apk

Also you can easily rewrite history on your own:

git rebase -i f92eec4c6af20783b08b4ba1c01f690a80bd01f0

Then set “edit” to first commit and once it’s started:

git rm ext-output/* -r
git rebase --continue

And repeat many many times. :mrgreen:

#252

SXX, looks like you failed rebase process

#253

No. There was failed build because I made it output find of every file and Travis consider log over 4MB as failure. So other than “commited by” it’s looks fine and build passed.

Now I also fixed uploading, but we certainly need Release build instead of Debug.
Sadly it’s still show horrible red screen on my device… :frowning:

#254

So I removed binaries from repository history:

$ du -hs ../BACKUP_ANDROID/vcmi-android/
301M    ../BACKUP_ANDROID/vcmi-android

$ du -hs ./vcmi-android
30M     ./vcmi-android

Can’t yet push it since master branch is protected. :cry:

#255

Ok I made backup and force pushed it. Hopefully I won’t break something for you. :slight_smile:

#256

GeneratedVersion was just meant to hold current vcmi version + git sha, but it doesn’t update correctly (it’s generated in cmake script and cmake sometimes uses cache instead of rerunning it – I guess I could move it to gradle script since I added git sha checking there anyway).

Well, yeah. It always is confusing and usually I break stuff when rebasing. :stuck_out_tongue:

I think I should add some dedicated “release” singing keys to repo (either generate new ones or just reuse default android’s debug keys because it doesn’t really matter).

Hmm, I guess this is the issue: bugzilla.libsdl.org/show_bug.cgi?id=2291 . I can try adding one of the possible solutions to the repo.

#257

Well, yeah. It always is confusing and usually I break stuff when rebasing. :PIt’s even more confusing since I had to mess with reflog. Also I still have no idea how to make GitHub purge orphan originals. I suppose it’s will remove them from reflog after default 2 week grace period, but we’ll see.

If some signing it’s the only difference in that case then I don’t care personally. I was worried “debug” build going to have worse performance since it’s might have some options disabled.

If you can please do. I still wish to attempt test of cross-platform multiplayer.

#258

Debug does have worse performance and we should switch to release.

In debug mode gradle script automatically signs the package using “internal” android debug keystore.
For release build gradle by default doesn’t sign the package and requires dev to specify “release” keystore (like I did with actual release vcmi keys in github.com/vcmi/vcmi-android/bl … radle#L149 (keeping them out of repo of course)). For release mode build on travis we need to specify some signing keys, but these can be any keys, including android “internal” keystore.

I’ll do it later (maaaybe today).

#259

Yep in that case we certainly need release builds and obviously I’ll prefer to not expose signing keys even on our server.

Also I tested multiplayer it’s works flawlessly. Though Android client crashed in Linux Host + MXE Windows guest + Android guest game, but I expect this could be result of fact how it’s loaded some extra mods or something.

PS: I also enabled daily build for your repository by Travis and added notifications to Slack.
Now we can track if we break building on Android all the time.

#260

I added possible fix for invalid colors here: github.com/Fayth/vcmi/blob/expe … T.cpp#L410 ). I’m not sure if you can somehow build it on your side or I should make a PR to develop?