[Ohrrpgce] Plan for Android 8.0 target

Fri Sep 28 07:53:25 PDT 2018

Oh, although the resulting .apk has a targetSdkVersion of 26 in its
AndroidManifest.xml, if I grep the output of build.sh I see:
Setting project property: target -> android-17
[gettarget] Project Target:   Android 4.2.2
[gettarget] API level:        17
etc
android-17 is actually the oldest "SDK platform" (as called in the Android
SDK Manage) which I have installed (as can also be seen by looking in
/opt/android-sdk-linux/platforms/). Although that never stopped the .apks
from running on my Android 2.2 phone.

On Sat, 29 Sep 2018 at 02:38, Ralph Versteegen <teeemcee at gmail.com> wrote:

> Well the even simpler solution is to just increase targetSdkVersion to 26
> in project/AndroidManifestTemplate.xml, without changing anything else, and
> see whether it works. I've done so, using NDK r12 (which I already had
> installed) and the latest SDK. It compiles and runs fine in an Android
> 4.2.2 emulator. I can't get Android 8.0 to run in an emulator. Maybe
> because only Atom system images are available, not ARM.
> As far as I can tell, targetSdkVersion is an SDK version number, it might
> have no effect at all on the NDK build tools. As I said, it changes runtime
> behaviour, wguke minSdkVersion is what is compiled against.
> The only information that I've managed to find about the requirement for
> increasing it is "minSdkVersion <= targetSdkVersion <= compileSdkVersion",
> where compileSdkVersion is the SDK version you have installed and seems to
> be a setting specific to other Android build tools; that string doesn't
> actually appear anywhere in the commandergenius tree.
>
> Which NDK version are you using, still the one I originally linked from
> the wiki Compiling for Android page (r9)?
>
> Oh, and Android nightly builds never did upload - it kept failing to
> connect to motherhamster.org. But now all nightly builds are down again
> anyway :P
>
>
> On Fri, 28 Sep 2018 at 23:51, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> Ah, so compiling with NDK r15 does sound like a better short term fix.
>> That might be easier, and could buy us time.
>>
>> I also really like the idea of moving our modifications to sdl_android
>> into Java files in the ohrrpgce code.
>>
>> On Thursday, September 27, 2018, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> Changing the target SDK changes system behaviour.
>>> According to
>>> https://developer.android.com/distribute/best-practices/develop/target-sdk#prenougat,
>>> setting the target to API 24+ (Android 7.0+) might break our function to
>>> email files. I'm not really sure, because the code calls
>>> "FileProvider.getUriForFile"... does that count as using FileProvider
>>> (required), or does that count as using a file:// URI (not allowed)? I
>>> think it's probably OK, but will need testing.
>>>
>>> On Fri, 28 Sep 2018 at 15:48, Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>> I found something else in a roadmap:
>>>> "2019 onwards: Each year the targetSdkVersion requirement will advance.
>>>> Within one year following each Android dessert release, new apps and app
>>>> updates will need to target the corresponding API level or higher."
>>>>
>>>> On Fri, 28 Sep 2018 at 15:17, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>> It drives me crazy that Android and its SDK and NDK use so many
>>>>> different version numbers and names, which don't match up in any way!
>>>>>
>>>>> A week ago there was this commit to pelya's port:
>>>>> "SDL: support for NDK r18, set minimum API level to 16 (Android 4.1),
>>>>> which is the minimum level NDK r18 supports"
>>>>> Switching to r18 is a big change because it gets rid of GCC and
>>>>> libstdc++. That's why so a bunch of work has been required in the SDL port.
>>>>> But if we can continue to use an older NDK then we don't need all these
>>>>> upstream changes from the SDL port.
>>>>>
>>>>> NDK r18+ supports Android 4.1+ (API 16+)
>>>>> NDK r15-17 support Android 4.0.0+ (API 14+)
>>>>> NDK r12-14 support Android 2.3+ (API 9+)
>>>>> Also, NDK r17 removed ARMv5 (armeabi) support, which is what we build
>>>>> for by default. Various deprecations as well.
>>>>> NDK r15 *(July 2017) *added Android 8.0 native APIs.
>>>>>
>>>>> So clearly NDK r15 can be used with Android 8.0 as the target, and it
>>>>> might even be possible to target Android 8.0 with earlier NDKs and SDKs. So
>>>>> I recommend we try to build with r15.
>>>>>
>>>>> Of course it would be nice to not be stuck on a years-old fork of
>>>>> pelya's port.
>>>>> Many of our additions to pelya's SDL 1.2 port should be moved to .java
>>>>> files contained in the OHRRPGCE source code rather than mixed in with
>>>>> unrelated code in project/java/Video.java
>>>>>
>>>>> Oh, also I just found this:
>>>>> "The Play Store will require 64-bit support when uploading an APK
>>>>> beginning in August 2019" "*32-bit support is not going away. Apps
>>>>> that include a 32-bit library just need to have a 64-bit version too"*
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 28 Sep 2018 at 12:43, James Paige <Bob at hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>> Oh, and I forgot to mention.
>>>>>>
>>>>>> Android 8.0 is the "target" but the apk files will still run on older
>>>>>> versions of android too.
>>>>>> The current "minimum" version supported by pelya's commadergenius
>>>>>> sdl_android is Android version 4.1
>>>>>>
>>>>>> (I looked up statistics, and apparently the percentage of android
>>>>>> devices running versions older than 4.1 is something like half of 1%)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 27, 2018 at 8:31 PM James Paige <Bob at hamsterrepublic.com>
>>>>>> wrote:
>>>>>>
>>>>>>> So starting pretty soon, only android apks that target Android
>>>>>>> version 8.0 will be allowed in Google play.
>>>>>>>
>>>>>>> I have done a little research, and I learned that pelya has done a
>>>>>>> lot of recent work on updating the commandergenius sdl for android port to
>>>>>>> work with the latest Android NDK.
>>>>>>>
>>>>>>> So here is my current plan:
>>>>>>> * I will clone a new fork of pelya's source
>>>>>>> * I will patch in or re-implement all the modifications that the
>>>>>>> ohrrpgce needs (this is mostly gamepad stuff and a few platform-detection
>>>>>>> functions. The ouya store purchase stuff can be removed completely)
>>>>>>> * I should be able to re-build the games that I have already
>>>>>>> packaged as apks
>>>>>>>
>>>>>>> I am glad I have a plan now, I was worried about that part-- but the
>>>>>>> bad news is that this plan is a lot of work, and my current free time is
>>>>>>> very limited right now.
>>>>>>>
>>>>>>> I am budgeting my time and so one hour each Thursday evening is
>>>>>>> "OHRRPGCE time" for the foreseeable future.
>>>>>>>
>>>>>>> Persons wondering how they can help without knowing how to comb
>>>>>>> through git commits and patch them onto a newer tree can help by sending me
>>>>>>> kind words and encouragement via e-mail on Thursday mornings to get me
>>>>>>> hyped up ;)
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>
>>>>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180929/29cc101d/attachment-0001.html>