We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Created attachment 2905 [details]
patch

Before gradle modification, here's a patch.

Some API 16 methods are used (InputDevice: getDescriptor(), getVibrator()), so we need to compile at least with SDK API 16. Hence default.properties and project.properties have been modified to use android-16.


There are also some modification to SDLActivity.java not to use getVibrator() if we run under API 16. And not to check to presence of hasVibrator() if we are under API 11.
-some hard-coded constant can be expandend.
- rename a local variable (hasVibrator to hasVibratorService)

This patch is in, thanks!
https://hg.libsdl.org/SDL/rev/04dd43a2c83a

Thanks to Sylvain for working on the patch, and to Sam for applying it!

For a quick test, I may now use "androidbuild.sh" to successfully create an APK.

I'm wondering, though, why has the "android:targetSdkVersion" attribute in AndroidManifest.xml not been increased to 16. I suppose the reason is that, if this were done, then certain compatibility behaviors would be removed/changed.

I don't really know neither the main reason ...
- if we keep targetSdkVersion API 16, it means we can still compile with SDK from API-16 to latest.

what I have noticed, it that if you submit an APK with targetSdkVersion 23 for instance, you cannot submit back an APK with targetSdkVersion 16.
Even if there is no code modified inside. So it goes always increasing.



According to:

 https://medium.com/google-developers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd

targetSdkVersion

The most interesting of the three, however, is targetSdkVersion. targetSdkVersion is the main way Android provides forward compatibility by not applying behavior changes unless the targetSdkVersion is updated. This allows you to use new APIs (as you did update your compileSdkVersion right?) prior to working through the behavior changes.

Much of the behavior changes that targetSdkVersion implies are documented directly in the VERSION_CODES, but all of the gory details are also listed on the each releases’ platform highlights, nicely linked in the API Levels table.

For example, the Android 6.0 changes talk through how targeting API 23 transitions your app to the runtime permissions model and the Android 4.4 behavior changes detail how targeting API 19 or higher changes how alarms set with set() and setRepeating() work.

With some of the behavior changes being very visible to users (the deprecation of the menu button, runtime permissions, etc), updating to target the latest SDK should be a high priority for every app. That doesn’t mean you have to use every new feature introduced nor should you blindly update your targetSdkVersion without testing — please, please test before updating your targetSdkVersion! Your users will thank you."










other links
 https://stackoverflow.com/questions/26694108/what-is-the-difference-between-compilesdkversion-and-targetsdkversion
 https://medium.com/google-developers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd
 https://developer.android.com/reference/android/os/Build.VERSION_CODES.html
 minSdkVersion (lowest possible) <= targetSdkVersion == compileSdkVersion (latest SDK)

(You may also want to see the patch to have gradle setup bug 3195)

Thanks!