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:
Well, I fixed the AppSudirsBuild but it still fails... At least it is failing differently! :) http://hamsterrepublic.com/tmp/makeapk- ... 4-fail.log
EDIT: I also tried symlinking the android/sdlmain.c file into my baconthulhu dir, but that did not help either:
http://hamsterrepublic.com/tmp/makeapk- ... fail-B.log
EDIT: I also tried symlinking the android/sdlmain.c file into my baconthulhu dir, but that did not help either:
http://hamsterrepublic.com/tmp/makeapk- ... fail-B.log
Last edited by Bob the Hamster on Fri Oct 25, 2019 1:43 am, edited 1 time in total.
I've seen this error before, when I was making these changes to the android build system. The problem is that none of the OHRRPGCE's source code at all is being compiled (or linked into libapplication.so), so in particular SDL_main is missing. I think it was because of a bad symlink (to wip/android/tmp instead of wip/android?).
Ah, the fact that you have a baconthulhu directory and symlinking sdlmain.c inside that directory causes that file to be compiled indicates that the problem is the contents of baconthulhu/. I hadn't really noticed before that you were doing this. Sure enough, by recreating this setup, creating a baconthulhu directory, copying android/*.cfg, sdlmain.c and icon.ping into it and symlinking wip/android/tmp to tmp inside it, I get the same error.
The problem is inside Android.mk, which is ignoring symlinks. I already had to fix this exact same problem elsewhere in Android.mk. OK, I've managed to fix the problem. Grab my latest "ohrrpgce" branch in the sdl-android repo.
Also, I see that you merged your ohrrpgce branch into your sdl_android branch (34a73bf23d was on your ohrrpgce branch when you merged it into sdl_android), so that it is no longer free of ohrrpgce-specific changes. So I'm not going to merge that. There were also some mixups - both you made a commit to the ohrrpgce branch that belonged to the sdl_android branch, and it also looks like you did a force push to github after I fetched changes, so a commit got (harmlessly) duplicated (and now I've duplicated it again).
OK, I've cleaned this up. I suggest you fast-forward your ohrrpgce branch to mine (i.e. pull/merge it, it will be a fast-forward), and do a hard reset (rewrite) of your sdl_android to mine, which contains everything (assuming my github repo is called "origin" for you: git fetch origin, git checkout sdl_android, git reset --hard origin/sdl_android)
You know... I made these changes to cleanup the android build system to save us time: so we wouldn't have to update hardcoded paths in ohrbuild.py in future, which we would surely forget to do. But those changes have cost us 100x the time we can ever hope to get back! I have to take away the lesson that cleaning up build systems is very risky, and the messier they are, the bigger the risk.
EDIT: I made a commit to svn too, and actually pushed my changes to github now
To fix:
-pull my 'ohrrpgce' commandergenius branch
-get latest svn rev (probably optional)
-make sure project/jni/application/baconthulhu/ etc contains the .cfg files, icon.c, and a symlink to wip/android/tmp. project/jni/application/ohrrpgce can just be a symlink to wip/android
Ah, the fact that you have a baconthulhu directory and symlinking sdlmain.c inside that directory causes that file to be compiled indicates that the problem is the contents of baconthulhu/. I hadn't really noticed before that you were doing this. Sure enough, by recreating this setup, creating a baconthulhu directory, copying android/*.cfg, sdlmain.c and icon.ping into it and symlinking wip/android/tmp to tmp inside it, I get the same error.
The problem is inside Android.mk, which is ignoring symlinks. I already had to fix this exact same problem elsewhere in Android.mk. OK, I've managed to fix the problem. Grab my latest "ohrrpgce" branch in the sdl-android repo.
Also, I see that you merged your ohrrpgce branch into your sdl_android branch (34a73bf23d was on your ohrrpgce branch when you merged it into sdl_android), so that it is no longer free of ohrrpgce-specific changes. So I'm not going to merge that. There were also some mixups - both you made a commit to the ohrrpgce branch that belonged to the sdl_android branch, and it also looks like you did a force push to github after I fetched changes, so a commit got (harmlessly) duplicated (and now I've duplicated it again).
OK, I've cleaned this up. I suggest you fast-forward your ohrrpgce branch to mine (i.e. pull/merge it, it will be a fast-forward), and do a hard reset (rewrite) of your sdl_android to mine, which contains everything (assuming my github repo is called "origin" for you: git fetch origin, git checkout sdl_android, git reset --hard origin/sdl_android)
You know... I made these changes to cleanup the android build system to save us time: so we wouldn't have to update hardcoded paths in ohrbuild.py in future, which we would surely forget to do. But those changes have cost us 100x the time we can ever hope to get back! I have to take away the lesson that cleaning up build systems is very risky, and the messier they are, the bigger the risk.
EDIT: I made a commit to svn too, and actually pushed my changes to github now
To fix:
-pull my 'ohrrpgce' commandergenius branch
-get latest svn rev (probably optional)
-make sure project/jni/application/baconthulhu/ etc contains the .cfg files, icon.c, and a symlink to wip/android/tmp. project/jni/application/ohrrpgce can just be a symlink to wip/android
Last edited by TMC on Fri Oct 25, 2019 5:44 am, edited 4 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! It is working!
I appreciate your help so very much!
Next to clean up my signing scripts, and actually try uploading a 64 bit Baconthulhu to Google Play
Oh, and thank you for the messed up sdl_android branch on my git, I have fixed it as you suggested.
EDIT: Okay, the apk files built successfully, and I signed them okay, but here is what Google Play tells me:
* First, it warns me that the TargetSDK 26 is too low, apparently TargetSDK 28 is required
I guess we have to get multiabi working (allthough if that turns out to be super difficult, maybe I'll try the different-version-codes thing as a stopgap)
I appreciate your help so very much!
Next to clean up my signing scripts, and actually try uploading a 64 bit Baconthulhu to Google Play
Oh, and thank you for the messed up sdl_android branch on my git, I have fixed it as you suggested.
EDIT: Okay, the apk files built successfully, and I signed them okay, but here is what Google Play tells me:
* First, it warns me that the TargetSDK 26 is too low, apparently TargetSDK 28 is required
Next it looks like it is impossible to upload both the 32 bit and 64 bit versions of the apk at the same time.Google Play wrote: Warnings
Your app currently targets API level 26 and must target at least API level 28 to ensure it is built on the latest APIs optimized for security and performance.
From August 2019, new apps must target at least Android 9.0 (API level 28).
From November 2019, app updates must target Android 9.0 (API level 28)
Maybe I could try hacking the build system make 32 bit and 64 bit with different version numbers, but that sounds messy, and I don't know if it will even work.Google Play wrote: Upload failed
You need to use a different version code for your APK or Android App Bundle because you already have one with version code 29.
I guess we have to get multiabi working (allthough if that turns out to be super difficult, maybe I'll try the different-version-codes thing as a stopgap)
Last edited by Bob the Hamster on Sat Oct 26, 2019 2:16 am, edited 3 times in total.
Wow, this is never-ending.
Specifying different version codes for different builds of the same same version is the correct way to do it and also the easiest way to do it; I believe we only need to adjust the version code rather than needing to modify both scons and build.sh to build and package multiabi apks, which sounds like a huge mess due to the scons android-source=1 kludge.
See https://developer.android.com/google/pl ... -apks.html
We could just make scons or makeapk.sh set the version code automatically according to the following rule:
armeabi: base version
arm64: base version + 100000
x86: base version + 200000
x86_64: base version + 300000
I haven't yet looked into what's required to target Android 9.0. It's likely that we'll need to pick more commits from upstream sdl-android.
Specifying different version codes for different builds of the same same version is the correct way to do it and also the easiest way to do it; I believe we only need to adjust the version code rather than needing to modify both scons and build.sh to build and package multiabi apks, which sounds like a huge mess due to the scons android-source=1 kludge.
See https://developer.android.com/google/pl ... -apks.html
We could just make scons or makeapk.sh set the version code automatically according to the following rule:
armeabi: base version
arm64: base version + 100000
x86: base version + 200000
x86_64: base version + 300000
I haven't yet looked into what's required to target Android 9.0. It's likely that we'll need to pick more commits from upstream sdl-android.
Last edited by TMC on Sat Oct 26, 2019 2:37 am, edited 4 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:
Reading the start of https://developer.android.com/google/pl ... ode-scheme, that's not ideal, because if you wanted to do a bugfix update for just the armeabi build (eg if there was a mistake building it) you would be forced to also rebuild and update the arm64 build (and make sure you release that one first), which would otherwise end up with a lower version number and cause all arm64 devices to downgrade to the armeabi build.
So I'd suggest instead V*1000 + A*100 + B where V is game version, A is arch and B is build number. And an extra digit spare use in future for other configurations.
I guess building multiapk packages isn't really so bad, since makeapk.sh has to run the build system multiple times anyway. I just realised we could run scons twice, once putting .c files in android/build/armeabi and once in android/build/arm64, and then run build.sh once (since it already supports creating multiabi apks, which saves us from packaging them ourselves) but somehow select between the different directory trees depending on the arch. And there are several options for that.
So I'd suggest instead V*1000 + A*100 + B where V is game version, A is arch and B is build number. And an extra digit spare use in future for other configurations.
I guess building multiapk packages isn't really so bad, since makeapk.sh has to run the build system multiple times anyway. I just realised we could run scons twice, once putting .c files in android/build/armeabi and once in android/build/arm64, and then run build.sh once (since it already supports creating multiabi apks, which saves us from packaging them ourselves) but somehow select between the different directory trees depending on the arch. And there are several options for that.
Last edited by TMC on Sun Oct 27, 2019 2:13 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:
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Every day, I turn on my macbook and open the ohr, only to realize that Tim Cook himself is standing right behind me, gun pressed against the back of my head. He whispers to me, "this application is not optimized for your Mac and needs to be updated." Sweat trickles down the back of my neck as I desperately try to pretend he's not there. I get little to no work done on my game. I sob softly as I realize the lack of productivity has nothing to do with Tim's empty threats. I'm now watching cat videos.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
- Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Oh, no, ha ha ha! Of course we can't move on! Google Play only supports API level 26 for another 72 hours!
We'll be trapped here forever!!! Ha Ha Ha
(But seriously, yes, the Mac thing sounds important. What is broken on Windows builds right now?)
EDIT: oh, I see it now. Windows only "slices.bas(4506) error 40: Illegal parameter specification in 'Sub report_slice_type_err(sl as Slice ptr, expected as SliceTypes)'"
We'll be trapped here forever!!! Ha Ha Ha
(But seriously, yes, the Mac thing sounds important. What is broken on Windows builds right now?)
EDIT: oh, I see it now. Windows only "slices.bas(4506) error 40: Illegal parameter specification in 'Sub report_slice_type_err(sl as Slice ptr, expected as SliceTypes)'"
Last edited by Bob the Hamster on Mon Oct 28, 2019 9:54 am, edited 1 time in total.
Turns out that the error message has been improved in the latest FB version:
"slices.bas(4506) error 41: Calling convention does not match DECLARE prototype in 'Sub report_slice_type_err(sl as Slice ptr, expected as SliceTypes)'"
Fixed.
Also I had a look over the behaviour changes when targetting Android 9.0 (API 28) and none of them are a problem for us. And there are no behaviour changes for API 27 (Android 8.1). So I guess the android major version number actually means something! So go ahead and bump the target API.
I also had a non-rigorous look at upstream sdl-android. Various interesting changes including a new signBundle.sh script replacing sign.sh/signUpload.sh (do you use sign.sh?) but nothing that looked important for us.
Of course, we don't even properly support API 26: the STORAGE permissions, and we're not sure whether sending emails still works.
Also I found this relevant note about a change when targetting API 26+:
"slices.bas(4506) error 41: Calling convention does not match DECLARE prototype in 'Sub report_slice_type_err(sl as Slice ptr, expected as SliceTypes)'"
Fixed.
Also I had a look over the behaviour changes when targetting Android 9.0 (API 28) and none of them are a problem for us. And there are no behaviour changes for API 27 (Android 8.1). So I guess the android major version number actually means something! So go ahead and bump the target API.
I also had a non-rigorous look at upstream sdl-android. Various interesting changes including a new signBundle.sh script replacing sign.sh/signUpload.sh (do you use sign.sh?) but nothing that looked important for us.
Of course, we don't even properly support API 26: the STORAGE permissions, and we're not sure whether sending emails still works.
Also I found this relevant note about a change when targetting API 26+:
...suppose an app lists both READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE in its manifest. The app requests READ_EXTERNAL_STORAGE and the user grants it. If the app targets API level 25 or lower, the system also grants WRITE_EXTERNAL_STORAGE at the same time, because it belongs to the same STORAGE permission group and is also registered in the manifest. If the app targets Android 8.0 (API level 26), the system grants only READ_EXTERNAL_STORAGE at that time; however, if the app later requests WRITE_EXTERNAL_STORAGE, the system immediately grants that privilege without prompting the user.
Last edited by TMC on Tue Oct 29, 2019 10:15 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: