0

If the targetSdkVersion is greater than the device OS version, and if I lower the targetSdkVersion to the device OS version, is the app going to behave differently ?

My application targetSdkVersion is 27 and I am running on a 8.0.0[26] device. I get an IllegalStateException as described in the below link, since I am using a dialog Activity.

java.lang.IllegalStateException: Only fullscreen opaque activities can request orientation

There were two options suggested. Removing android:screenOrientation="portrait" from AndroidManifest.xml or changing the targetSdkVersion to 26. Both the solutions are working for me.

But my question is regarding changing the targetSdkVersion to 26. How is the app behavior going to change when we lower the targetSdkVersion from 27 to 26 and the device OS is 26? Since the device is running in 26 and the targetSdkVersion is 27, I don't think any compatibility modes are applied. My understanding is, the compatibility mode is applied, when the device OS version is greater than the targetSdkVersion.

So how is the app behaviour changing when we change the targetSdkVersion here?

lloydpick
  • 1,638
  • 1
  • 18
  • 24
nks
  • 253
  • 1
  • 3
  • 9
  • 1
    You shouldn't lower the targetsdk level. Your app will be blocked from the play store eventually. Always target the latest Android Api level https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html – Shmuel Apr 19 '18 at 19:29
  • Thanks for the info. I ended up using the other option. But just curious to know how lowering targetSdkVersion solves the above issue – nks Apr 19 '18 at 19:31

2 Answers2

0

Potential yes, your app is going to behave differently. When you set targetSDKVersion to 27 your app will be compiled against the API 27 SDKs and linked with the API 27 libraries. If the newer SDK and libraries contain a change that your app code hasn't allowed for then your app could exception. Lowering the targetSDKVersion means the app is built against the early SDK and you do not need the code modified for the later SDK changes and thus no exception. However, you lose the ability to use the new features of the later SDK and shorten the time the app stays in the Play store, as older APIs are eventually dropped.

Remember that targetSDKVersion has nothing to do with device API support. It is SDK compile version. A targetSDKVersion of 26 will run on a device that supports API 27. A targetSDKVersion of 27 will run on a 26 API device if you do not use any API 27 features (the workaround is to use the support library versions of the new features, if they have been provided, sometimes new API features do not appear in the support library).

Daniel S. Fowler
  • 1,982
  • 15
  • 12
  • When targetSDKVersion is 27, I agree it is compiled against the API 27 SDKs. But when it is run in a device with API 26, it should be accessing the API implementations of API 26 right ? To make it more clearly - the Exception is thrown from the onCreate function. onCreate function of API 27 has the condition check which causes the Exception. But when the built apk runs on API 26 device, which does not have the condition check, which causes the exception, it should not matter if the targetSdkVersion is 27 or 26 right ? – nks Apr 20 '18 at 13:56
  • Also as you pointed out - When you set targetSDKVersion to 27 your app will be compiled against the API 27 SDKs and linked with the API 27 libraries - The API 26 device does not have the 27 SDKs and API libraries right ? – nks Apr 20 '18 at 13:58
  • Yes, an API 27 app on an API 26 device will call the API 26 code even though it is linked to API 27. Due to backwards compatibility, it will not exception unless new API 27 code is called (which is obviously not in an API 26 device, and hence the use of the support library to sometimes provide new API functionality). – Daniel S. Fowler Apr 20 '18 at 18:12
  • So you mean to say when API 27 app is running on API 26 device, the v27 support libraries are causing the exception ? And when we lower the targetSDKVersion to 26, support library v26 are getting included ? – nks Apr 20 '18 at 18:30
  • If you are referring to the IllegalState exception above then the reason for that is covered in the answers in the provided link. A v27 support library should not cause an exception on an API 26 device (unless used incorrectly or the library itself has a bug). The version of the support library used is set in the build.gradle file. – Daniel S. Fowler Apr 22 '18 at 12:16
0

Yes, the Android docs have mentioned behaviour changes when targetSdkVersion is changed. For example, back in API 19 we were told that Android 4.4's WebView operates in "quirks mode" in apps that target API level 18 and lower, as well as AlarmManager and ContentResolver keeping some of their old behaviour for such apps. We were also told about a small change to WifiConfiguration in Android 6 that checks if targetSdkVersion is 20 or lower, and a temporary reprieve on linking to non-NDK platform libraries in Android 7 if targetSdkVersion is 23 or lower. More dramatic was the bunch of Android 8 behaviour changes, some of which check for targetSdkVersion being 26 or above before giving you the new behaviour. Basically they want you to read the "Behaviour Changes" sections of every new API that comes out.

Silas S. Brown
  • 1,469
  • 1
  • 17
  • 18
  • But then how exactly is the device OS version affecting these behaviors ? In my case the device is on 26.0.0. And the changes added a particular API for targetSdkVersion 27 in the Android code base should not be affect the API in v26 ?Unless the device is upgraded to v27, how is it going to be aware of the changes added in v27 ? – nks Jun 11 '18 at 19:56
  • Sounds like a possible bug in API 26 to me. On an API 26 device, it may make a difference if target is 25 versus 26, but it SHOULDN'T make a difference if target is 27 versus 26. If it does, it's plausible that some API 27 code was accidentally released early and you've managed to activate it. If you can simulate an API 25 device I'd try to reproduce on that first to verify that the problem is specific to an API 26 device. You could then detect the API at runtime and make it not run the affected code on 26, or just re-code that whole section to avoid using the affected part of the API. – Silas S. Brown Jun 13 '18 at 06:40