3

I have an application that behaves differently when compiled for API 18 and 19 (behaviour of repeating alarm).

I compiled my application for API 19 (Google API). I ran it on device, and saw that the Build.VERSION.SDK_INT returned 16.

I understand that this says that 16 is the maximal API number that my device can run currently.

I just wanted to verify: In such a case, will my app run the same on such a device, regardless of whether I compiled it for API 18 or 19?

Gari BN
  • 1,635
  • 2
  • 17
  • 31
  • I advice you to look on that post - http://stackoverflow.com/questions/4568267/android-min-sdk-version-vs-target-sdk-version – Tal Kanel Jan 14 '14 at 14:47

3 Answers3

2

Target API != your device api

For example, if you set target API to be 16, you can access all API with version <= 16 When you run on a device with newer API, it would still works as all public API should be backward compatible

But in some cases, the target API does change the app behaviour. For example, kitkat webview has changed a lot, some old code actually have conflict with the kitkat api. But to keep backward compatibility, it would not crash with target api < kitkat. But if you set target api to be kitkat, it means you know the new api changes in kitkat, it does crash if you run those old problematic code. To keep device with old sdk working, you would need to check the sdk version of device, and run different code in different sdk.

So for your case, if you need the alarm fire exactly the time you set, here is the code:

    if (Utils.isKitKatOrLater()) {
        am.setExact(AlarmManager.RTC_WAKEUP, timeInMillis, pendingIntent);
    } else {
        am.set(AlarmManager.RTC_WAKEUP, timeInMillis, pendingIntent);
    }
Bear
  • 5,138
  • 5
  • 50
  • 80
2

I have an application that behaves differently when compiled for API 18 and 19 (behaviour of repeating alarm).

The core behavior of AlarmManager is not dependent upon how you compile the app. It is dependent upon the OS level of the device and, more importantly, your android:targetSdkVersion.

The only difference in AlarmManager based upon how you compile the app (i.e., your build target, Project > Properties > Android in Eclipse), is whether you have direct access to additional methods (e.g., setExact()) on newer devices.

In such a case, will my app run the same on such a device, regardless of whether I compiled it for API 18 or 19?

This is impossible to answer in the abstract, even if we convert "compiled it" to "set the android:targetSdkVersion". Some behavior changes will occur on newer devices regardless of android:targetSdkVersion; some behavior changes will occur on newer devices only if your android:targetSdkVersion is set to that API level or higher.

In the particular case of AlarmManager, some of this is covered in the JavaDocs for the particular Build.VERSION_CODES value of interest, such as KITKAT:

AlarmManager.set becomes interpreted as an inexact value, to give the system more flexibility in scheduling alarms.

It is also echoed in the documentation for AlarmManager itself, such as:

Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Your example is better than me because it is related to the alarm which the users ask. haha – Bear Jan 14 '14 at 14:48
  • I really talked about the "AlarmManager.set becomes interpreted as an inexact value, to give the system more flexibility in scheduling alarms". So, if I compile my code for API 19, and it runs on device with API 16, it will behave as though I compiled it for API 16 (the alarms should run in exact times)? – Gari BN Jan 14 '14 at 14:51
  • 1
    target api 19 + device api 16 ---> behaviour with api 16 – Bear Jan 14 '14 at 14:53
  • @GariBN: Yes. However, that should be considered a stop-gap measure. Eventually, you will find *something* that will coerce you into wanting to raise your `android:targetSdkVersion` to 19 or higher. But this gives you a window in which you can budget the time to rework your `AlarmManager` code to take into account these changes. – CommonsWare Jan 14 '14 at 14:54
  • @Bear It is strange, because I see that the alarms are fired not very accurately (although, I can't run it on API 19 device to compare). – Gari BN Jan 14 '14 at 14:55
  • 1
    @GariBN: "I see that the alarms are fired not very accurately" -- there are any number of possible problems (e.g., using `_WAKEUP` alarms without using the `WakefulBroadcastReceiver` or `WakefulIntentService` patterns) that can cause this. You can also use **`adb shell dumpsys alarm`** to see currently-scheduled alarms. – CommonsWare Jan 14 '14 at 14:55
1

You should use emulators...
Set as many as you can, running devices with different OS versions.
I know they are slow, but they are an invaluable help.

Your device runs on API Level 16 because there's Jelly Bean installed (version 4.1 or version 4.1.1).
So it's backward compatible up to minSdkVersion (as defined in your Manifest).

Your targetSdkVersion should always be the latest.

Phantômaxx
  • 37,901
  • 21
  • 84
  • 115