VCMI for Android

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.

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

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

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:

SXX, looks like you failed rebase process

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:

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:

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

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.

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.

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

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.

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?

I think I could just cherry-pick it, but would be handy if you can add some argument to Android build scripts that Travis trigger. So in future we can just create new branch in vcmi-android with modified Travis config and it’s will make build for us. :wink:

E.g like:

# Now we have
python3.5 ./build.py build-app
# But we can do
python3.5 ./build.py build-app HEAD
python3.5 ./build.py build-app develop
python3.5 ./build.py build-app experimental/sdl-color-fix

OR even better. Expose that argumnent and I’ll implement travis script that let us trigger build by creating new branch in vcmi-andoid like:

buildForMe/feature/ambientSounds

And it’s will build “feature/ambientSounds” branch from upstream.

Also in future we can just make Android builds on every commit / branch / PR just like we do for Linux GCC, Linux Clang, MXE and Mac. Sadly that would take time to implement and I have tons of other tasks on project right now.

Ok. For now it’s set to only build “fa02900” commit from develop.
Please make it always build develop HEAD and also get rid of “internalData.zip”.

Now I just no longer sure git submodules is right tool for the task there.
So probably this need to be changed at least for Travis builds…

So I don’t want to disrupt your workflow. Should we just implement cloning of actual VCMI develop instead of using submodule when it’s build by Travis?

I’m not very knowledgeable about more complex git stuff, so just go ahead if you see a solution. :slight_smile:

Can we just add git commands to .travis.yml?

  • switching to correct branch based on external param
  • git pull in the submodules (but this might be not needed because switching to the branch should use latest commit?)

I just not sure it’s actually worth to use submodule in this situation. :slight_smile:
Probably I missing something, but most likely they not intended for that kind of use. E.g there no way to make git automatically grab latest commit. I’ll check how we can solve this.