Android google-play compat status thread
Moderators: Bob the Hamster, marionline, SDHawk
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Android google-play compat status thread
This thread is for met to post progress reports on how Android build compatibility with Google Play's new stricter requirements is progressing.
Today I managed to un-break the Android nightly build virtual machine.
I had correctly merged tmc's needed changes to the sdl_android code, but what was screwing me up was that I had an old android/tmp.2 folder which was a copy of android/tmp left over from when I was testing something a while ago.
Now that the android build is smart enough to search for files to compile, it was picking up those copies too, and I was getting a bunch of duplicate definition errors
I also had to resize the virtual machine's hard drive so I would have space to install the correct newer Android API inn the Android SDK.
So that means that the android nightlys should (knock on wood) start building properly tonight.
It also means that I can once again easily make 32 bit apk files for people.
My next step is to try again to upgrade from NDK r8d to NDK r12b which will allow me to finally try making 64-bit apk files.
Today I managed to un-break the Android nightly build virtual machine.
I had correctly merged tmc's needed changes to the sdl_android code, but what was screwing me up was that I had an old android/tmp.2 folder which was a copy of android/tmp left over from when I was testing something a while ago.
Now that the android build is smart enough to search for files to compile, it was picking up those copies too, and I was getting a bunch of duplicate definition errors
I also had to resize the virtual machine's hard drive so I would have space to install the correct newer Android API inn the Android SDK.
So that means that the android nightlys should (knock on wood) start building properly tonight.
It also means that I can once again easily make 32 bit apk files for people.
My next step is to try again to upgrade from NDK r8d to NDK r12b which will allow me to finally try making 64-bit apk files.
Last edited by Bob the Hamster on Mon Oct 14, 2019 12:23 am, edited 1 time in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Guess who has two thumbs and compiled a 64 big apk?
Not me, Hamsters don't have thumbs!
So I made another clone of my virtual Machine, and today I upgraded my NDK version to r12b.
This broke 32 bit Android builds. I don't know why.
But ndk r12b did make it possible to successfully make a 64 bit android build by passing arch=arm64 to scons!
So there is now a 64 bit apk sitting in http://hamsterrepublic.com/ohrrpgce/nightly/
I tested installing it on my Pixel 1 and playing a game (Feenix's WitchX) and it worked great! No obvious problems.
Next I tried building a 64 bit Cyrpt of Baconthulhu apk, but that failed. for some reason distrib-nightly-android.sh worked, but misc/makeapk.sh failed, and I haven't figured out why yet
So progress in baby steps.
Build-logs with ndk r12b
* Here is how distrib-nightly-android.sh fails building 32 bit https://pastebin.com/raw/Na1VLxWA
* Here is how distrib-nightly-android.sh succeeds building 64 bit https://pastebin.com/raw/Rd2GCZAv
* Here is how makeapk.sh fails to build 64 bit https://pastebin.com/raw/z6bekfra
Not me, Hamsters don't have thumbs!
So I made another clone of my virtual Machine, and today I upgraded my NDK version to r12b.
This broke 32 bit Android builds. I don't know why.
But ndk r12b did make it possible to successfully make a 64 bit android build by passing arch=arm64 to scons!
So there is now a 64 bit apk sitting in http://hamsterrepublic.com/ohrrpgce/nightly/
I tested installing it on my Pixel 1 and playing a game (Feenix's WitchX) and it worked great! No obvious problems.
Next I tried building a 64 bit Cyrpt of Baconthulhu apk, but that failed. for some reason distrib-nightly-android.sh worked, but misc/makeapk.sh failed, and I haven't figured out why yet
So progress in baby steps.
Build-logs with ndk r12b
* Here is how distrib-nightly-android.sh fails building 32 bit https://pastebin.com/raw/Na1VLxWA
* Here is how distrib-nightly-android.sh succeeds building 64 bit https://pastebin.com/raw/Rd2GCZAv
* Here is how makeapk.sh fails to build 64 bit https://pastebin.com/raw/z6bekfra
At last!
I've never seen the "undefined reference to '__srget'" error before, but a web search shows that the NDK r10c changelog lists __srget as being removed (that's a "bugfix") and this is where it's declared in bionic stdio.h (bionic is Android's libc). In other words, the libc version used to provide the stdio.h header doesn't match the libc version being linked against.
Sure enough checking the build log I see that ./obj/local/armeabi/libfb.a is being linked, but this library wasn't built -- it's using a copy that was built with the previous NDK version! I'm surprised because I had thought that whenever I run build.sh it recompiles libfb.a... although I see it doesn't always happen, as my libfb.a is older than my libapplication.so. I guess I just change FB branches frequently enough that it gets rebuilt a lot.
Solution: rm -rf ./obj/local/*
I'd totally forgotten about makeapk.sh. I don't really understand the contents. For example, why does it do this?
Looking at the build log I can see that the problem is (again) that the .c files in /home/james/src/ohr/wip/android/tmp/lib aren't being picked up by ndk-build's makefile. Does that imply that makepkg.sh is checking out the wrong branch?
As for people creating their own .apks, the current best solution for that is Chronoboy's ohrrpgce-android.
I did some work on it as recently as April. It doesn't do it yet, but the plan is for it to download the android nightly and pull the binaries out of that, so the only things you will need to produce an .apk are Python and the Android SDK (and Java, if that's not included in the SDK?), not the NDK, scons, OHRRPGCE source code, FreeBasic and GCC. Currently it just includes out of date copies of the binaries.
(Sadly bitbucket is dropping Mercurial support on June 1st 2020, so we need to move elsewhere.)
I've never seen the "undefined reference to '__srget'" error before, but a web search shows that the NDK r10c changelog lists __srget as being removed (that's a "bugfix") and this is where it's declared in bionic stdio.h (bionic is Android's libc). In other words, the libc version used to provide the stdio.h header doesn't match the libc version being linked against.
Sure enough checking the build log I see that ./obj/local/armeabi/libfb.a is being linked, but this library wasn't built -- it's using a copy that was built with the previous NDK version! I'm surprised because I had thought that whenever I run build.sh it recompiles libfb.a... although I see it doesn't always happen, as my libfb.a is older than my libapplication.so. I guess I just change FB branches frequently enough that it gets rebuilt a lot.
Solution: rm -rf ./obj/local/*
I'd totally forgotten about makeapk.sh. I don't really understand the contents. For example, why does it do this?
Code: Select all
git checkout "${BRANCHBASE}"
git checkout "${BRANCHBASE}"_"${BRANCHSUFFIX}"
As for people creating their own .apks, the current best solution for that is Chronoboy's ohrrpgce-android.
I did some work on it as recently as April. It doesn't do it yet, but the plan is for it to download the android nightly and pull the binaries out of that, so the only things you will need to produce an .apk are Python and the Android SDK (and Java, if that's not included in the SDK?), not the NDK, scons, OHRRPGCE source code, FreeBasic and GCC. Currently it just includes out of date copies of the binaries.
(Sadly bitbucket is dropping Mercurial support on June 1st 2020, so we need to move elsewhere.)
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I'll try this today! :)Solution: rm -rf ./obj/local/*
As for the git checkout "${BRANCHBASE}"_"${BRANCHSUFFIX}" business, that is just about game-specific button overlay images
BRANCHBASE is always ohrrpgce and BRANCHSUFFIX is the gamename. When that branch does exist, it will just be a copy of the ohrrpgce branch with button images replaced.
Yesterday I was testing with Crypt of Baconthulhu, and branch ohrrpgce_baconthulhu does not exist at all because Baconthulhu uses the default button images.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
I did:
That seems to have fixed the 32 bit build with NDK r12b http://hamsterrepublic.com/tmp/distriba ... uccess.log (Yay!)
When I have a little more time, I'll try to improve the nightly build script to build both the 32bit and 64 bit apk files on a single VM.
makeapk still fails. http://hamsterrepublic.com/tmp/makeapk- ... 4-fail.log but at least it is failing differently than before ;)
Code: Select all
rm -Rf ~/src/sdl-android/project/obj/local/*
When I have a little more time, I'll try to improve the nightly build script to build both the 32bit and 64 bit apk files on a single VM.
makeapk still fails. http://hamsterrepublic.com/tmp/makeapk- ... 4-fail.log but at least it is failing differently than before ;)
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
So I improved the distrib-nightly-android.sh and now it can build both a 32 bit apk and a 64 bit apk using NDK r12b
If all goes well, it will start doing that with tonight's nightly builds.
I am still utterly baffled about why makeapk fails with NDK r12b.
Here is a failed build log (properly capturing both stdout and stderr this time) http://hamsterrepublic.com/tmp/makeapk- ... 0-fail.log
(EDIT: the above failed makeapk.sh build log is from the same VM where distrib-nightly-android.sh succeeds for both arches)
If all goes well, it will start doing that with tonight's nightly builds.
I am still utterly baffled about why makeapk fails with NDK r12b.
Here is a failed build log (properly capturing both stdout and stderr this time) http://hamsterrepublic.com/tmp/makeapk- ... 0-fail.log
(EDIT: the above failed makeapk.sh build log is from the same VM where distrib-nightly-android.sh succeeds for both arches)
Last edited by Bob the Hamster on Sun Oct 20, 2019 8:19 pm, edited 1 time in total.
-
- Slime Knight
- Posts: 258
- Joined: Thu Nov 16, 2017 5:22 am
I for one am ecstatic you're working on this! I know I'm not alone. Very big deal for the engine!
Last edited by ArtimusBena on Mon Oct 21, 2019 1:27 am, edited 1 time in total.
This doesn't seem right. I can see that it tries to compile ohrrpgce-custom and reimport autotest.hss (which fails because android-source=1 doesn't actually build binaries)*, but makepkg.sh doesn't do that. James, are you sure you're running the copy of makepkg.sh that's actually in svn? When you posted a build log a week ago it didn't try to compile ohrrpgce-custom
* makepkg.sh should instead contain "scons ... || exit 1"
* makepkg.sh should instead contain "scons ... || exit 1"
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
http://hamsterrepublic.com/tmp/makeapk- ... 1-fail.log
Okay, this is weird.
It seems to be trying to run scons test even though it should just be doing scons game
I realize that I don't understand SConscript well enough to figure out what is wrong here, so I guess next time I'll be reading its documentation :P
Okay, this is weird.
It seems to be trying to run scons test even though it should just be doing scons game
I realize that I don't understand SConscript well enough to figure out what is wrong here, so I guess next time I'll be reading its documentation :P
I see what's going on. It turns out that acts the same as (. for the current directory) and tried to build all build targets. The empty argument is being passed to scons by "${ARCHARGS}". You could ensure ARCHARGS=arch=armeabi or ARCHARGS=arch=32 in the 32 bit case instead of empty.
"scons ." doesn't actually run the tests, but it does try to update autotest.rpg by reimporting scripts.
Code: Select all
scons ""
Code: Select all
scons .
"scons ." doesn't actually run the tests, but it does try to update autotest.rpg by reimporting scripts.
Last edited by TMC on Tue Oct 22, 2019 1:45 am, edited 2 times in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Yay! You are the best! Thank you for noticing that.
Unfortunately it still fails, differently. http://hamsterrepublic.com/tmp/makeapk- ... 2-fail.log
Also, now I am wondering, how the heck was my distrib-nightly-android.sh script ever working? Because of a typo, I was defining $ARCHARGS but actually using $ARCH_ARGS so I was always passing "" to scons no matter what. It failed today as expected, but I am baffled as to how it was working fine for me yesterday. I don't know.... looks like my $SCRIPTDIR variable was being used wrong too :P
Unfortunately it still fails, differently. http://hamsterrepublic.com/tmp/makeapk- ... 2-fail.log
Also, now I am wondering, how the heck was my distrib-nightly-android.sh script ever working? Because of a typo, I was defining $ARCHARGS but actually using $ARCH_ARGS so I was always passing "" to scons no matter what. It failed today as expected, but I am baffled as to how it was working fine for me yesterday. I don't know.... looks like my $SCRIPTDIR variable was being used wrong too :P
Oh great (not actually), now we're back to square one! Not finding lib/... That isn't anything to do with scons. Hey, wait a minute. You gave baconthulhu a custom AndroidAppSettings.cfg file? You need to update it, because I changed a line in that file in svn. It should contain:
Rather than maintaining custom AndroidAppSettings.cfg files, it would be far better to only put the stuff unique to a game in a separate .cfg file, and include it at the bottom of AndroidAppSettings.cfg, like we already do with extraconfig.cfg (which contains anything generated by scons). We're likely to make further changes to AndroidAppSettings.cfg in future. Maybe we could just add an arg to scons that adds an include line to extraconfig.cfg. Or appened it in makeapk.sh
But meanwhile, although the nightly android build worked a few days ago, since r11336 "distrib-nightly-android.sh now compiles both 32bit and 64 bit apk files" it's been it's been failing because it tries to reimport autotest.hss. As you said, $ARCHARGS broke it. So it appears that it never successfully built a 64 bit .apk - I'm guessing the 64 bit apk that was uploaded was you running it manually?
Code: Select all
AppSubdirsBuild=
But meanwhile, although the nightly android build worked a few days ago, since r11336 "distrib-nightly-android.sh now compiles both 32bit and 64 bit apk files" it's been it's been failing because it tries to reimport autotest.hss. As you said, $ARCHARGS broke it. So it appears that it never successfully built a 64 bit .apk - I'm guessing the 64 bit apk that was uploaded was you running it manually?
Last edited by TMC on Wed Oct 23, 2019 2:54 pm, edited 5 times in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact: